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GENERA.™G and IMPLEBIEmiNG A SIGNAL PROTOCOL 
AND INTERFACE FOR HIGHERBATA RATES 

CM>SS-REFERENCE TO RELATED APPLICATIONS 

[0001] The present Application for Patent claiins priority to Provisional Application 

No. 60/475,459 entitled "Generatdng aitid iMplemenling a Signal Pix^toeol and Interfade 
for Higher Data Rates" filed June 2, 2003, and assigned to the assignee heieof and 
hereby expressly incorporated by reference herein. 

BACKGROUND OF TBE INVENTION 

I. Field Of the Invenfion 

[0002] The present invention relates to a digital signal protocol and process for 

comiTLunicating or transferring signals between a host device and a client audio/visual 
presentation device at high data rates. More specifLeaily, the present invention relates to 
a technique for transferring multimedia and other types of digital signals from a wireless 
device to a micro-display unit or other presentation device using a low power high data 
rate transfer mechanism. 

n. Related Art 

[0003] Computers, electronic game related products, and various video technologies 

(for example DVD's and High Definition VCRs) have advanced significantly over the 
last few years to provide for presentation of increasingly higher resolution stUl, video, 
video-on-demand, and graphics images, even when including scHoe types of text, to end 
u&eis of such equipment. These advances in turn mandated the use of higher resolution 
electronic viewing devices such as high definition video monitors, HDTV monitors, or 
specialized image projection elements. Combining such visual images with high- 
definition or -.quality audio data, such as when using CD type sound reproduction, 
DVDs, and other devices also having associated audio signal outputs, is used to create a 
more realistic, content rich, or true multiinedia experience for an end user. In addition, 
■ highly mobile, high quality sound systert^ and music transport mechanisms, such as 
MPS players, have been developed for audio only presentations to end users. 
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[0004J In a typical ^adeo presentation scenario, video data is typically transferred using 

current techniques at a rate that ccmld be best termed as slow or medium, being on the 
order of one to tens of kilobits per second. This data is then either buffered or stored in 
transient of loflgef-terin memory devices, for delayed (later) play out on a desired 
viewing device. For example, images may be transferred "across" or using the Internet 
using a program resident on a computer having a modem or internet connection device, 
to receive or transmit data useful in digitally representing an image. A similai- transfer 
can take place using wireless devices such as poatable computers equipped with wireless 
modems, or wireless Personal Data Assistants (PDAs), or wireless telephones. 

[0005] Once received, the data is stored locally in memory element!?, circuits, or 

Jlv'^J'^, 'dJ^ ^ R \tvi o' fla^h memorj inclu'-hT^e; i.\ •'r^c*' -f*n, ^ t'^tH*"-. 'Oi 
pbjDac< ~>'='|.vntin <z oi tlte imount of ddta -incl me ii'vae if-Mmj ion tne pU>bdCk 
iip^bf hr^iin ifljtiN'el'i cii!f liv o he picscnt* d w till nmji -h j1)(Ji.1i\ lhatis ui some 
lii-iUta s It i^t-pLSLiiu 1 1 1 u 1 1 d te ifi li deg e3 i t timL, plcitb,.!.] lor >L.rv 
- <■ i o loA r„ ij K ) 1 Ji •> T J 1 i la ci ^liT ji c l-^p or 

firre-' i t i -it i „ i " i . ' i u i ii i \li t m i i i-n i=, 

being transferred. Provided there are no interruptions in the transfer link, once the 
presentation begins the transfer is reasonably transparent to the end user of the viewing 
device. 

[0006] The data used to ^rsatr. c -t -■r- , -] I * j mages or motion video are often compressed 

hsin2 ore ^ . i j ^ ' " ^ ..|UJt. such as those bp^i^iued bv the Joint 
Fiiolo-iijf'h - > ( "PEG) the Motion P t ure Expert" Group (MPEG), and 
-11 1 f - I '11! . n ^o miprtiii 1 (1 Ihi iicdj, c < w put^A and 

crnim uiu i jn'- i i n ^ n <-[ i \ tr mstei ot data ovei a Lomtnunivdlion link. 
ThK allows ixanafemng images or data faster by using a smaller number of bits to 
transter a siven amount ol mtormaiion. 

[0007] un.e the aaa i irani^ftTrtd it> a ''lot d de>i' f ^tnli a ■ fon^i i, r or other 

recTp'ei* rev^ tie le^iltrng irifoimdlion is uii-i f^mp ■^'^^ed (f| ]>p^3,cd us ng special 
decod p ft uc ''f m(i deu»>j(.d li ntedtd, a .d puortiid to o ii i p esentation 
based on the coireaponding available presentatooii resoLution and control elements. For 
L,\a. -f L c t%p,t u coinpt tcr video resolution in tenr'^ or '-.crc; re. j1 L of X by Y 
pixels typically ranges from as low as 480x640 pixels, through 600x800 to 1024x1024, 
although a variety of other resolutions are generally jK>ssible, either as desired or 
needed. 
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[0008] toiage presentation is also affected by the iroage content and the ability of given 

video controllers to manipulate the image iii temis of certain predefined color levels or 
color depth (bits per pixel used to generate colors) and intensities, and any additional 
overhead bits being employed. For example, a typical computer presentation would 
anticipate anywhere from around 8 to 32, or more, bits per pixel to represent various 
colors (shades md hues), although other values ai^e encounteied. 

f0009] From the above values, one can see that a given screen image is going to require 

the transfer of anywhere ftom 2.45 Megabits (Mb) to around 33.55 Mb of data over the 
range from the lowest to highest typical rewlutioris and depth, respectively. Wten 
viewing video or xooiwn type jrr.ai7CK r.* a vzzc of if) triimes per second, the amount of 
data required rs arounc 73,/ to 1,0U() MeaJv.ts of dr.ta per second (Mbps), or around 
9.ii lo 125.75 M.;gabyiea per seroiKl (MB[!s). addition, one may desire to present 
audio uasa in coiijnrn-.:ion ivji'i im\f,!e-. ^dch i< for imiltimcdia presentation, or as a 
sepiwatc high resolution audio piesenlation, such as CD quality music. Additional 
iignalE. dealing vv.th ,nrer,ics v: c,!!",-,. .— s. cc-i. o~ i zr.ds may also be employed. 
Each of these options- i.d.lii.'^ -wr, r-r-.- ■ir.'.z I-- -;;/T-t;'iicd. In any case, when one 
desires to transfer high qii.ir.i}' or i.igii lei-oiuliou iw.i^i: d:t(.L- imd high quality audio 
informa.:ion or dati' t-igtials io an end user to create a content rich experience, a high data 
transfer rate link is rec]uiK-d between presenta!io.a dements and the source or host 
dcvb-efhul . j.tovide such types .> ; ' 

[0010] Data rates ol aromid 115 Kilobytes' (KBpsj or, 9^0 Kilobits per second (Kbps) 

can be rouimcly handled t?y modem serial itileifaceL. Giher interfaces such as USB 
serial interfaces, can accommodate data transfers ai: tale? as high as 12 MBps, and 
^^.^."Ih;;/-^-;! spu-'i 'ransfeis . li 'v i_ (I't; hi^titute of Electrical 

and Electronics Engineers (TEfE) 11 '^ ,u i ,^ ^ \ .1 ra.e- c a the order of 100 
to 400 MBps. Unfortunately, these rates fall short of the desired high data rates 
discussed above which are contemplated for use with future, wireless data devices and 
services for providing high resolution, content rich, output signals for driving portable 
video displays or audio devices. In addition, these interfaces require the use of a 
significant amount of host or system and cKeait softwai'e to operate. Their software 
protocol stacks also create an undesirably large amount of overhead, especially where 
mobile wireless devices or telephone applications are contemplated. Such devices have 
severe memory and power consumption limitations, as well as alteady taxed 
computational capacity. Furthermore, some of these interfaces utilize bulky cables 
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which are too heavy and imsatisfEKtory for highly aesthetic oriented mobile 
applications, complex connectors which add cost, or simply consume too much power. 

[0011] There are other known interfaces such as the Analog Video Graphics Adapter 

(VGA), Digits Video Interactive (DVI) or Gigabit Video mterface (GVCF) interfaces, 
nie first two of these are parallel type interfaces which process data at higher transfer 
rates, but also employ heavy cables and consome large amounts of power, on the order 
of several watts. Neither of these characteristics are ameaaable to use with portable 
consumer electronic devices. Even the third interface consmnes too much power and 
uses expensive or bulky connectors. 

[0012] For some of the above interfaces, and other very high rate data 

systems/protocols or transfer mechanisms i^ociated with data transfers for fixed 
installation computer equipment, there is another major drawback. To accommodate 
the desired data transfer rates also requires substantial amounts of power and/or 
operation at high Current levels. This greatly reduces the usefulness of such techniques 
for highly mobile consmner oriented products. 

[0013] Generally, to accommodate such data transfer rates using altemalis'es such as 

ba> optical tiber t\pi- co<^r< , o ^ and tiansfcr elements. Jilsi- ;i.iL ii n'h i of 
additional converter ! introduce rnuch no^e coiTaple\.r>' and c^st, fhan 

desirea % a truly . _ i . ! rrodi.c \",(ie fron- the gcncrsily 

e<[WM\e ri.i uif ji 1 ! ' ' e- rsaunements and complexity 

p.cNcnr- ooneiil til,. |( i • imi winx p Hur^le i<p^>l<j 4101';. 

[0014] Whut lux: Ivui aUit>i in t'it ndus.is iot (h- uihh^ ... TTu,'nil^ jppl« itions, is a 

leLnaC(„v to proM^c a II qiUiht^,' LiiowMrotion expi'ticji^t- wU ht !> 1 dto, video, 
or rruil^medid ba'^ed tcr hiirhly ii.rni3 end useis. Tha is \[ i 1 ; porldble 
t f)jiEpi(i -rs v 'fie-qs pb'inr PDjis, t o hiEj'My mobib LuroiTLiK (. „r d^.' .co- or 
tqi'i'iuil, IrK cnieir vidf">^ anl ii.in n -=1.1 .■•11,11 c/su^nii 'jcvKr^ "cirj; used 
■^111,) taiKiOi. dc[nu oulpiK 4l .1 ^ired Pioh nvili^t I'"'"'"' '"^""'t-i, t]=- rr ed 
quality that is lacking is the result of anobtaiBable high data rates needed to transfer the 
high quality presentation data. Therefore, a new transfer mechanism is needed to 
increase data throughput between host device.? providing the data and client display 
devices or elements presenting an output to end users, 

[0015] Applicants have prop:.-c„ 'Lr- ^ r j, qfei nicchdmsms in US Patent 

AppMcation Serial Nos. 10/020,520 and 10/236,657, both entitled "Generating And 
Implementrng A C^Kmmunication Protocol And Interface For ffigh Data Rate Signal 
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Transfer", which are assigned to the assignee of the present invention and incorporated 
heredn by reference. The techniques discussed in those applicaticais can greatly improve 
the transfer rate for large quantities of data in high speed data signals. However, the 
demands fdc ever increasing data rates, especially as related to video presentations, 
continue to Even with other ongoing developments in data signal technology, 

there is stMl a need to strive for even fastei- transfer rates. Therefore, there is a 
continuing need to develop a new or iitiproved transfer mechanism which is needed to 
increase data throughput between host and client devices. 

SUMMARY 

[0016] The above drawback, and others, existent in the art are addressed by 

embodiments of the current inventicfn in which a new protocol and data transfer 
mechanism has been developed for transferring data between a host device and a 
rescipient client device at high data rates. 

[0017] Embodiments for the invention are directed to a Mobile Data Digital Interface 

(MDDI) for transferring digital data ar .i, J. . , u,. , ,, h,.q i i„. and a client 
device over a communication path which employs a |:)liu ality oi series of packet 
structurieis linked together to fomi a communication protocol for communicating a pre- 
selected set of digital coniroi and presentation data between the host and client devices-. 
The signal communications pi oiocol or link layer is used by a physical layer of host or 
client linlc controUers. At least one link controller residing in the host device is coupled 
to the client device through the cosiimmiicalions path or link, and is configured to 
generate, tra!i!:ii-u aid r.*ccive packets fcmiirg the coniriiunicaliona protocol, and to 
form digital presentation data into one or more types of data packets. The interface 
provides for bi-directional transfer of information between the host and client. 

[0018] In further aspects of embodiments of the invention, at least one client link, 

controller, or client receiver, is disposed in the client device and is coupled to the host 
device through the communications path or link. The client link, controller is also 
configured to generate, transmit, and receive packets, forming the communications 
protocol, and to form digital presentation data into one or more types of data packets. 
Generally, the .host or link controlier employs a state machine for processing data 
packets used in commands or certain types of signal preparation and inquiry processing, 
but ean use a slower general purpose processor to manipulate data and some of the less 
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complex packete used in the comimmication protocol. The host contioller comprises 
one or more differential line drivers; while the client receiver coraprises one or more 
differential line receivers coupled to the coirammication pafh. 

[0019] The packets are grouped together within media frames that are commmiicated 

between the host and client devices having a pre-defiiied fixed length with a pre- 
determined number of packets having different variable lengths. The packets each 
comprise a packet length field, one or more packet data fields, and a cyclic redundancy 
check field. A Sub-&ame Header Pticket is transferred or positioned at the beginning of 
transfers of othei- packets from the host link controller. One or more Video Stream type 
packets and Audio Stream type packets are used hy the communications protocol to 
transfer video type data and audio type data, respectively, from the host to the client 
over a for^^ard link for presentation to a client device user. One or more Reverse Link 
Encapsulation type packets are used by the communications protocol to- transfer data 
from the client device to the host link controller. 

[0020] Filler type packets ai'e generated by the host link controller to occupy periods of 

forward link transmission that do not have data. A plurality of other packets are used by 
Ihc comraiinications protocol to transfer video information. Sucli packets include Color 
Map, Bit Block Transfer, Bitmap Area Fill, Bitmap Pattern Fil!, and Transparent Color 
1 etc t\i>" 1 1 J -K I'^v " . S*. 11 !\p^ p'lckets are used by the 
co-nmunic r . v ! fi-ed data. Keyboard Data and 

Fwintir ^ Ul» 1 > i ' I I [ ^ ( 'J ' V 'I . c jmnii'mcations protocol to transfer 
!. I'a (> or OF'i i'hLi irput '"...t 'iiLO i3i ^ ' H'jln L 'i^iv device. A Link Shutdown 
t)pe packet is used i ^ tl < ^ i in m i un«, t u i 1 tr t. rmmate the transfer of data in 
cilhra- diicclion < 

[0021] The cnmmmivation i)...tl l, a t lh p >-t-v o employs a cable having a series 

of lour or more conductors and a sRiela. In some embodiments the link controllers 
*ni II-.- ? I SB data inleiiace and die cable u&cb a USB type interface along witli the 
otlier ctmductors. In addition, piintcd wrres or flexible conductors can be used, as 

[0022 I c i-'-t hnk (..o itJollei lequests aisp a / i^ctpiLalitji s mfonnation from tlie client 

acMC^ ir o d_i tc dct.cinnrc what type if da'a ard Ch^Xo uuis said client is capable of 
accj] 1 fj_dU tiihf^'^ 1' xi^dce The c'letit li'"! c >rli Jler communicates display 
or presentation cjt()abilraes to the host lirtk controller using at least one Display 
Capabihty type packet. Multiple transfer modes are used by the communications 
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protocol with each allo\ving tlie transfer of different maximum jmHibers of bits of data 
in parallel ovci- a given time period, with each mpde sejectable by negotiation between 
the host and client link controllers. These traiisfer tpodes are dynamically adjustable 
during transfer of data, and the saine mode ineed riot be used on the reverse Imk as is 
used on the forward link. 
[0023] In other aspects of some embodiments of the invention, the host device 

comprises a wireless communications device, such as a vvireless telephone, a wireless 
PDA, OT a portable computer having a wireless tnodem disposed therein. A typical 
client device comprises a portable video display sach a v-iicrfi-display device, and/oi" 
a portable audio presentation system Furthr .n i , i l'^- i r iisc storage means or 
elements to store presentation or multimedia daia to be a-ansfeiTed to be presented to a 
client device user. 

BRIEF DESailPTION OF THE DRAWINGS 

[0024] Fuithei: features and advantages of the invention, as well as the stracture and 

operation of various embodiments of the invention, are deseribed in detail below with 
■ refeitince to the accompanying drawings.. In the drawings, like reference mimbers^ 
generally indicate identical, functionally similar, and/or structurally similar elements or 
processing steps, and the drawing in which an element first appears is indicated by the 
leftinost digit(s) in the reference number. 

[0025] HG.. lA iUusti-atBS a basic environment m wiiich emDocfcments of the invKitian 

might operate including the use of a micro-display device used ui cojjjmietion with a 
portable computer. 

[0026] HG. IB illustrates a basic environment in which embodiments of the invention 

might operate including the use of a micro-display device and audio presentation 

elements used in conjunction with a wireless transceiver. 
[0027] FIG. 2 illustrates the overall concept of a Mobile Digital Data Interface with a 

host and client interconnection. 
[0028] FIG. 3 illustrates the stracture of a packet meM for realizing data transfers fcom 

a client device to a host device. 
[0029] FIG, 4 illustrates the use of an MDDI link controller and the types of signals 

passed between a host and a client over the physical data link conductors for Type I and 

Ty\}e U interfaces. 
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[0030] FIG. 5 illustrates the use of an MDDI link controller and the types of sigiwls 

passed between a. ho?t and a client over the phj^ical data link conductors for Tj'pes H, 
II, and IV interfaces. 

[0031] FIG. 6 illustrates the struetuie of ftaraes and sub-ffames used to implement the 

Interface protocol. 

[00321 FIG. 7 illustrates the general structure of packets used to implement the 

interface protocol. 

[00331 FIG. 8 illustrates the format of a Sub-frame Header Packet. 

[0034] FIG. 9 illustrates the foimat and contents of a Filler Packet 



[0035] 


HG. 


10 illustrates the fonmat of a Video Stream Packet. 


[0036] 


HG. 


11 illustrates the format and contents for. the Video Data Format Descriptor 




of FIG. 10. 




[0037] 


eG 


i 2 iilL"-ii^iiei ill'' 'ise of parkfd i"h1 i "park'd ioii"f<is \vi data. 


[0038] 


FIG 


i 3 ilius iriie-, iht^ inTu tm' n ^.luiui ,ini Pai Kel 


[0039] 


HLs 


U .llii, a.t , tl. IS. '< . ill, .J pr.rls^-. l'C\I formats for data 


[0040] 


FIG. 


liu . ' ! I t. i 5( <m Packet 


[0041] 


"IG 


•i., "U-' H vli I ^ ^ " 2. - > ■ ..L 


[0042] 


FIG 


17 illus'ra'es th" (t* . , i i i Ercip'^-j' ii-o" Packet. 


[0043] 


FIG 


]? i !u,' K 1 ■ " - ' i\ C ^'i-i )1 ^ r-cl.->t 


[0044] 


nc. 




[0045] 


no. 


Jj Lj,u.-.li.i.t 1 il ...toiniat of a Pointing DcviceDaiaAu'vCt 


[0046] 


FIG. 


.2 1 1 . msti ates the format of a Link Shutdown Packet. 


[0047] 


f-IG. 


22 illusfxates the format of a Display Request and Status Packet. 


[0O48j 


FIG. 


23 illustrates the format of a Bit Block Transfer Packet. 


[00491 


FIG. 


24 illustrates the format of a Bitmap Mea. Fill Packet. 


[0050] 


FIG. 


25 illustrates the format of a Bitmap Pattern Fill Packet. 


[0051] 


:fig. 


26 illustrates the format of a Communication Link Data Channel Packet. 


[0052] 


HG. 


27 illustrates the format of a Interface Tj^je Handoff Request Packet. 


[0053] 


FIG. 


28 illustrates the format of an Interface Type Acknowledge Packet. 


[0054] 


FIG. 


29 illustrates the fomi-at of a Perform Type Handoff Packet. 


[0055] 


FIG. 


30 illu;:itrates Lhe fornxat of a Forward Audio Channel Enable Packet. 


[0056] 


HG. 


31 illustrates the format of a Reverse Audio Sample Rate Packet. 


[D057] 


HG. 


32 illustrates tlie format of a Digital Content Protection Overhead Packet. 


[0058] 


FIG. 


33 illustrates the format of a Transparent Color Enable Packet. 
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[0059] FIG. 34 illustrates the format of a Round Trip Delay Measurement Packet. 

[006O] FIG. 35 illustrates the timing of events during the Roimd Trip Delay 

Measiirement Pacfcet, 

[0061] FIG. 36 illustraces a sample implementation of a CRC generator and checker 

useful for implementing the invention. 
[0062] FIG. 37A illustrates the timing of CRC signals for the apparatus of FIG, 36 

when sending data packets. 
[0063] HG, 37B illustrates the timing of CRC signals for the apparatus of FIG . 36 when 

receiving data packets. 

[0064] HG. 38 illustrates processing steps for a typical service request with no 

contention. 

[0065] FIG. 39 illustrates processing steps for a typical service request asserted after the 

link restart sequence has begun, contending with link start 
[0066] FIG. 40 illustrates how a data sequence can he transmitted using DATA-Sl'B 

encoding. 

[0067] FIG. 41 illustrates circuitry useful for generating the DATA and STB signals 

from input data at Ihe host, and. then recovering the data at the client 
[006 S] FIG. 42 illustrates drivers and terminating resistors useful for implementing one 

embodiment. 

[0069] FIG 43 iUu,E , , < . .. I . J . .ployed by a client to secure service 

from the hott and b) ip-^ hob lo pr \ lUc oiioh iiervite. 
[0070] FIG 44 ilin>-" relative spacmg between transitions on the DataO, other data 

lines (TicU T i il tt -^in i ^ 
[0071] J-ICi t , 1 1 1 iy in response that can occur when a host 

disablct, the host flnvcr i u j. Ir i>K rr -g -i picket 
[0072] FIG, 46 illustrates the presence of a delay in. response that can occur when a host 

enables the host driver to transfer a packet. 
[0073] FIG. 47 illustrates the relationship at the host receiver input between the timing 

of the data being transferred and the leading and trailing edges of die strobe pulses. 
[0074] FIG. 48 illustrates switching characteristics and corresponding client output 

delay developed by the reverse data timing. 
[0075] FIG. 49 illustrates a high level diagram of signal processing steps and conditions 

by which synehromzation can be implemented using a state machine. 
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[0076] FIG, 50 illustrates typical amounts of delay encountered for signal processing on 

the forward and reverse paths in a system emplojing the MDDI. 
[0077] FIG. 5 1 illustrates marginal roimd trip delay measurement. 

[0078] FIG. 52 illustrates Reverse :Link data Me changes. 

[0079] FIG. 53 illustrates a graphical representation of values of the Reverse Rate 

Divisor versus forward linlc data rate. 
[0080] FIGS. 54A and 54B illustrate steps undertalten in the operation of m interface. 

[0081] FIG. 55 illustiales m overview of the interface apparatus processing packets., 

[0082J FIG. 56 illusti'ates the format of a Forw^ard Link Packet 

[0083] FIG. 57 illustrates typical values for propagation delay and skew in an Typ&-I 

Link interface, 

[0084J HQ. 58 illuistrates Data, Stb, and Clock Recovery Timing on a Type-I Link for 

exemplary signal processing through the interface. 
[0085J FIG. 39 illustrates typical values for propagation delay and skew in Typcrll, 

Type- III or Type-IV Link interfaces. 
[0086] FIGS. 60A, 60B, and 60C illustrate different possibilities for the timing of two 

data signals and MDDLStb with respect to each other, being ideal, eaiiy, and late,, 
respectiveiv, ■ 

[0087] ■RG 61 illustrates mt'-ihc iss ^i > i !•' -v Tirei - r« .bed ^Mth. a 

1 vpe-LType-n mterfaces. 
[OOS; I flGS f iA and C2B .1 . V - ' ' . ^ MDUl S v cfoiras 

torboth I)T3e l.md ivpe Illrtc 1 . l cl 1 
[0089] HG e^iilu trateb ihi^jhlc^'-l in i i « i ni i> » i ssmf steps md 

LondiLions bv which ynchromzatioi l n i i i u f 1 i i i k i t iiik 
[009n ,Kf tj-r 11 iracs t vuh!)h^^. It, li i ( .tLOcl> cycles 

[0091] FIG. 65 illustrates exemplary eraor code transfer processing. 

[009 '] FIG 06 il'U!>"-a< -b apparatus useful for error codp " I'l^fci pin c^^ u" 

[0093] FIG. 67 A illustrates error code transfer processing for code overloading. 

[0094] FIG. 67B illustrates error code transfer processing for code receptiorL 

[0095] FIG. 6SA illustrates processing steps for a host initiated wake-up. 

[£K)5K5] FIG. 68B ilhistrates processing steps for a client initiated wake up. 

[0097] HG. 68C illustrateg processing steps for host and client initiated wake-up with 
contention. 
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DETAILED DESCRiraON OF THE EJflBODIMENTS 



I. Overview 

[0098] A genml intent of the invention is to provide a Mobile Display Digital Interface 

(NdDDI), as discussed below, which results in or provides a cost-effective, low power 
consumption, transfer mechanism that enables Mgh- or very-high- speed data transfer 
over a short-range communication link between a host device and a display device using 
a "serial" tj^e of (fata link or chanoel. Tiiis mechanisra lends itself to implementation 
with riiiniature connectoiB and thin flexible cables which are especially useful in 
connecting display elements or devices such as wearable micro-displays (goggles or 
projectors) to portable computers, wireless communication devices, or entertainment 
devices. 

[0099] An advantage of embodiments of the invention is that a technique is provided 

for data transfer that is low in complexity, low cost, has high reliability, fits well within 
the environment of use, and is very robust, while reanaining very flexible. 

[00100] The present invention, can used in a variety of situations to communicate or 

transfer large q 1. 1 "ii -f data, generally for audio, video, or mul imedia applications 
from a hosf i- h)"H i d e v^here such data is generated or %'axed. tu a client display 
orprei^nid'Ki'i d(.\ "V i' .i j;h rale. ^ • 'I d"OM, u.hich ii> JiaCiaased below, is 
the tran^U^JT ot datu. lr^>rrt itic- a p^ir^ ib . , - , u • .i a wireless telephone ur modem to 
a visi\L LHtpiuy dc\ic'c bucr. as .i-.:... .i-.>w'j ttrccn or u 'Aciirabic micru-dibplay 
appliai.f t'ich as. ifi ^hi furni oi ;joi.'iieb oi haimels cjiiiuiu'-g bmall projection icities 
md sctueris, oi from i lio".! m Juin device within smh coiiiponcntfe That is, fi«im a 
proce; i»,n.i i , ■ l presentation elerm, n I 

[OOlOl] The characteristics or attributes of the MDDl are such that they are independent 

of specific dispL^y technology. This ;s a highly flexible mechanism for transferring data 
at a high rate without regards to the internal structure of that data, nor the functional 
aspects of the data or commands it implements. This allows the timing of data packets 
being transferred to be adjusted to adapt to the idiosyncrasies of particular display 
devices, or unique display desires for certain devices, or to meet the requirements of 
.eorabined audio and video for some A-V systems. The interface is very display element 
or client device agnostic, as- long as the selected protocol is followed. In addition, the 
aggregate serial link data or data rate can vary over several orders of magnitude which 
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alloy's a commonication s>^tem or host device designer to optimize the cost, power 
requirements, client device complexity, and display device update rates. 
[00102] The data interface is presented primarily for use in transferring large amounts of 

high rate data over a "wired" signal link or small cable. However, some applications 
may talce advantage of a wireless link as weU, including optical based links, provided it 
is coofigured to use the same packet and data structures developed for the interface 
protocol and can sustain the desired level of transfer at low enough power consumption 
or complexity to remain practical. 

II. Environment 

[00103] A typical apphcation can be seen in FIGS.. 1 A and IB where a portable or laptop 

computer 100 and wireless telephone or PDA device 102 ai-e shown communicating 
data with display devices 104 and 106, respectively, along with audio reproduction 
systems. 108 and 112. In addition, FIG lA shows potential connections to a larger 
. ■ display or screen 114 or an image prqiector 116, which are only shown in one figure for 
clarity, but arc conncctabic to wireless device 102 as well. The wireless dtevice can be 
currently receiving d.ttlii .'j>r hitve previously stored- a certain amount of multimedia tyjie 
data in a memory element or device for later presentation for viewing and/or hearing by 
an end user of the wireless device. Since a typical wireless device is used for voice and 
simple text comm-anicriUons most of the time, it has a rather small display screen and 
simple audio system (spetikers) for communicating information to the device 102 user. 

[00104] Computer 100 has a much larger screen, but sdll inadequate external sound 

system, and still falls short of other multimedia presentation devices such as a high 
definition television, or movie screens. Computer 100 is used for purposes of 
illustration and other types of procs.ssor.s, interactive video games, or consumer 
electronics devices can also be used witli the invention. Computer 100 can employ, but, 
is not limited to or by, a wireless modem or other built in device for wireless 
Gommunications, or be connected to such devices using a cable or wireless link, as 
desired, 

[00105] This makes presentation of more complex or "rich" data a less than a useful or 

enjoyable experience. Therefore, the industry is developing other mechanisms and 
devices to present the information to end users and provide a minimum level of desired 
enjoyment or positive experience. 
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[00106] As previously discussed aboye, several types of display devices have or are 
currently being developed for presenting information to end users of device 100. For 
example, one or more companies have develc^ed sets of wearable goggles that project 
an image in front of the eyes of a device user to present a visual display. When 
coitectly positioned such devices effectively "project" a virtual image, as perceived by a 
users eyes, that is much larger than the element providing the visual output. That is, a 
very small projection element allows the eye{s) of the user to "see" images on a much 
larger scaiv Quin possible with typical LCD- screens and the like. The use of larger 
virtual screen images also allows the use of much higher resolution images than 
possible vidth more limited LCD screen displays. Other display devices could include, 
but are not limited to, small LCD screens or various flat panel display elements, 
projection lenses and display diivers for projecting images on a surface, and so forth. 

[00107] There may also be additional elements connected to or associated with the use of 

wireless device 102 or computer 100 for presenting an output to another user, or to 
■another device which in turn transfers the signals elsewhere or stores them. For 
.example, data may be stored in flash memory, in optical form, for example using, a 
. writeable CD media or on magnetic media such as in a magnetic tape recorder and 
■ similar devices, for later use. 

[00108] In addition, many wireless devices and computers now have built-in MP3 music 

dttt'dt iL * i J 1> n ■, v' - ' o lei d .need sound decoders and systems. Portable 
computers utilize CD and DVD playback capabiHiies as a general nile, and some have 
small dedicated flash memory readers for receiving pre-recorded audio files. The issue 
with having such capabilities is that digital music files promise a liighly increased 
feaiuiv .'ch i <.y,r^- I ; . ' ii. .),.:y f the decoding and playback process can keep pace. 
The same holds true for the digital video files. 

[00109] To assist with sound reproduction, external speakers 1 14 ai-e shown in FIG. la, 

which could also be accompanied by addition elements such as sub-woofers, or 
"surround-sound" speakers for front and rem- sound projection. At the same time, 
speakers or earphones 108 are indicated as built-in to the support frame or mechanism 
of micro-display device 106 of HG. lb. As would be known, other audio or sound 
reproduction elements can be used including power amplification or sound shaping 
devices. 

[001 10] In any case, as discussed abovcj when one desires to transfer high quality or high 

resolution image data and high quality audio information or data signals from a data 
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source to an end user over one or more commmication links 1 10, a high data rate is 
required. That is, transfer link 110 is clearly a potential bottleneck in the 
communication of data as discussed earlier, and is liaiiting system perforniance, since 
current transfer mechanisms do not achieve the high data rates typically desired. As 
discussed above for example, for higher image resolutions such as 1024 by 1024 pixels, 
with color depths of 24-32 bits per pixel and at data rates of 30 fps, the data rates can 
approach rates m excess of 755 Mbps or more. In addition, sacli images may be 
presented as part of a multimedia piiesentation which mcludes audio data and potentially 
additional signals deahng with interactive garamg or commumcations, or vanous 
commands, controls, or signals, further increasing the quantity or data and the data rate, 

[0011 1 1 it r iL'^ uesr that fewer cableb or interconnections required for es*^abli'?b'ng a 

aara iint medtis t m^-vbile devices associated with a f^i^pu^ jh' e lo t td 
iTiorc- ro ue £!«k,p H'i bv a nrf,e' u^er 5 <5se Fbis t^ i spi laij y tnjc \\h „ niutiiiic 
ul\kl-;= au t,tiii.nunjv u->eu -,111 i iJii es-pcSiCicc ^nd nioie 

^tp^u llv ^ i^.ual k' .1 ' di re irc e ■^e 

[001)2] s 1! it 1 k " - ' 111 i! , I . 1 b-e fo- 

f'-ap t 11 I s n ■ < tl h 1 II rt ate- ft'i 

'■"eda^^a jt-nitej; 'ii K "I cfom ■ , ■ ! 1 -^hh 1 o Jtn <ii d h^' data 

-oj- c ^vl "Ch rll A^-i \y- ujtl; low^ '1 li il , ati 1 bs , iirle a,ia 

Cii o 1 -al iri'li^-j *ru^'ure db po&hible. Ap--. ^. v ^ca eJooed a new tec^inique. 
01 TTL^-h'^d a^d tx-sfj? i * ^ c Ihcbe dv ' ^iLt d i L d luv ^\ u ^ t>1 i-li e 

pOtl^l'^' 0« "Wii-i 1] ^ fO 1 -1 --H 11-" O (lr"5!r^i illsj ( I H 

ubplajrs, or audio udn fti tkiuuiitb, di veiy high data rates, Awhile mdiniaui iig <* de^ueu 
low power consumption, and complexity. 



m,. High Rate Digital Data Interface System Architecture 

[00113] In order to create and efficiently utilize a new device interface, a signal protocol 
aiid^ system architcGture has been formulated that provides a very high data transfer rate 
using low power signals. The protocol is based on a packet and coimnon frame 
structure, or structures linked together to form a protocol for communicating a pre- 
selected set of data or data types along witii a command or operational structure 
impost on the interface. 
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A. Overview 

[00114] The devices connected by or commitnicating over the MDDI link are ealled the 
host and client, with the client typdeally being a display device of some type. Data ftom 
the host to the display travels in tiie forwai-d direction (refened to as forward traffic or 
link), and data from the display to the host travels in the reverse direction (reverse 
traffic or link), as enabled by the host, lliis is iUustrated in the basic configuration 
shown in HG. 2. In FIG. 2, a host 202 is connected to a client 204 using a. bi- 
directional eoinmimication channel 206 which is illustrated as comprising a foiwanl 
linlt 208 and a reverse link 210. However, these channels are formed by a common set 
of conductors whose dxrta transfer is effectively switched between tiie forward or reverse 
link operations. 

[OD J 15] As discussed elsewhere, the host comprises one of several types of devices that 

can benefit from using the present invention. For example, host 202 could be a por|:able 
computer in the form of a handheld, laptop, or similar mobile computing device, it 
could be. a PDA, a paging device, or one of many wireless telephones or modems. 
Alternatively, host 202 could be a ponablc cntjrtaiiiincnt or presentation device such as 
a portable DVD or CD player, or a game playing device. At the same time, client 204 
could comprise a variety of devices useful for presenting information to an end user. 
For example, a micro-display incorporated in goggles or glasses, a projection device 
built into a hat or helmet, a small screen or even holographic element built into a 
vehicle, such as in a window or windshield, or various speaker, headphone, or sound 
systems for presenting high quality sound or music. However, those sldlled in the art 
will readily recognize that the present invention is not limited to tliese devices, there 
being many other devices on the market, and proposed for use, that are intended to 
provide end users with high quality images and sound, either in terms of storage and 
transport or in terms of presentation at playback. The present invention is useful in 
increasing the data throughput between various devices to accommodate tlic higli data 
rates needed for realizing iJie desired user experience. 

B. . Iiiterface Types 

[0011,6] The MDD Interface is contempJated as addressing five or more, somewhat 

distinct :physical types of interfaces found in the communications and computer 
industries. These are labeled at this point simply as Type-I, Type-II, Type-Ill, Type-lV 
andType-U. 
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[001 17J The T>'pe--I interface is configored as a 6~wire (conductor) interface which 

makes it saitablc for mobile or wireless telephones, PDAs, e-Books, electronic games, 
and poitabJe media players, such as CD players, or MP3 players, and devices on similar 
types of electronic consumer technology. The Type-U interface is configured as an 8- 
wre (conductor) interface which is more suitable for laptop, notebook, or desktop 
IKsrsonal computeis and similar devices or applications, that do not require tlie display to 
be updated rapidly and do not have a built-in MDDI linic controller. This interface type 
is also distinguishable by the use of an additional two-wire Ufliversal Serial Bus (USB) 
interface, which is extremely useful in accGmmodating existing operating systems or 
software support found on most persona] computers. Type-U interfaces can also be 
used in a USB-only mode where the display simply has a USB connector that connects 
to a standard USB port on a computer or similar device, for example a consumer 
. . electronics device equipped with such a port, such as digital cameras or video players. 

[001 18J , Type-IL Type-m, and Type-IV interfaces are suitable for high performance 
displays or devices and use larger more complex cabling with additional twisted-pair 
t>pe conductors to providis tl^; appropriate shielding and low loss transfers for data 
signals, 

[00119] The Type-I interface passes signals which can comprise both the display, audio, 
control, and limited sigitaling information, and is typically used for devices that do not 
require high-resolution full-rate video data. This type of interface is primarily intended 
for devices, such as mobile wimiess devices, where a USB host is typically not available 
within the device for connection and transfer of signals. In this configuration, the 
mobile device is a MDDI host device, and acts as tiie "master" that eontrols the 
communication link from the host, which generally sends display data to the client 
(forward. traffic or linlt). 

[00120] In this interface, a host enables receipt of commtmication data at the host from 

the chent (reverse taffic or link) by sending a special command or packet type to the 
client thai allows it to take over the bus (link) for a specified duration and send data to 
the host -as reverse packets. This is illustrated in HG. 3, where a type of packet referred 
to as an eneapsulation packet (discussed below) is used to accommodate the transfer of 
reverse packets over the transfer link, creating the reverse link. The time interval 
allocated for the host to poll the display for data is pre-determined by the host, and is 
based on tiie requirements of each specified application. This type of half-duplex bi- 
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directional data transfer is especially advantageous where a USB port is not available 
for tiansf er of information or data form the client. 

[00121] The Type-U inlerfiiee tranvSferB signals whicb aiie well suited for use in laptop 

and desktop applications where a USB interface is widely supported by extensive 
amounts of motiierboaids or other hardware, and by operating system software. The use 
of an ad^d USB interface allows use with "plug-and-play'' features and easy 
application configuratioiL The inclusion gf USB also allows general-purpose bi- 
directioffal flow of commands, status, audio data, and so forth whtle video and audio 
data intended for the client device can be transferred using the twisted pairs at low 
power and high speed Vmjsi ^^.n tran^'tcrrcd unra ct^'er Mres rs discussed below 
Embodiments of the ir^er loi u^n^ a USB nterf'^e allo\. biLn sp^cd transfei<; o^'ei 
one set of conductor' » ni imp enienlmg mainlv ^.i"! dnrio .^o citinwl nrouuh ine 
USB connectiun, which c in nr On i mi unen ti ") it tl-^«- itid i ssD^m ( i jui c pi>\M,i 

[00122] 'Ihe USB . i uscu standa d to. mrd^m i .r'=o m 

computer cquipmcnl, i d l a o t !_5B nt^rfacc and its optiation aie en well 
tnown in the an, so not cxDlamcd rscrc. For the u5B mtertacc. commumc-alioii belWBen 
the host and display are compliant wun Lne lli i >-is d Stiiil Bus Spt-uhu iln a Ke v!->!on 
2.0. In applications using the Type-U interface where USB li. the {- ir-tLv signal -ng 
channel and possibly a vo t r > f t is optional iur -h*.- 1 ost to poll the clieut 
through the MDDI serial data signals. 

[00123] High-performarcc d'^n,^ . . p.^.c ol HDTV type or similar ngh re^o'itfont 

require around 1.5 Gbj*. tc>te ddtd itrpitais, in oi'ter to support full-moiion vidpn "he 
Type-II interface support 1 s"l < i •< l n mj ti g "> nis ^ rdiJ] ! h-^ 1 s 

•by transrnitting 4 bii:s n m K] ii h IqelV r lert ice tiansters b bits m pm d lei 
The protocol used by iW MDD^ 'h \> i h T>pt T - T1 111 oi IV ho t to ccn..iall\ 
communicate with an V Ivpc ' 1' iJ n c'lC-n* O'^ di l " i^c;" a i it 

the highest data rate P3E: bib 'e -> I " ^" ~W npd'^ibii*'^ <> i il 1- e If i i r^" 
what can be referred to as the least capable device is used to set the pertbrmanGe of the 
link. As- a rule, even for systems where the host and client are botli capable using Type- 
n, Type-^IU, or Type-IV interfaces, both begin operation as a Type-I interface. The host 
then determines the capability of the target client or display, and negotiates a hand-off 
or reconfiguration operation to either Type-U, Type-Ill, or Type-IV mode, as 
appropriate for the particular application. 
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100124] It is generally possible for the host to use the proper link-layer piotocol 

(discussed further below) and at any time to step down or again reconfigure operation to 
a slower mode to save power or to step up to a faster mode to support higher speed 
transfers, such as for higher resolution display content. For example, a host may change 
display modes when the display system switches from a power source such as a battery 
to AC power, or when the source of the display media switches to a lower or higher 
lesolution format, or a combination of these or other eonditions or events may be 
considered as a basis for changing a display or data transfer mode. 

[00125] It is also possible for a system to communicate data using one mode in one 

direction and another mode in another direction. For example, a Type IV interface 
mode could be used to transfer data to a display at a high rate, while a Type I or Type U 
mode is used when transferring data to a host device from peripheral devices such as a 
keyboard or a pointing device. 

. C. Physical Interface Structure 

[00126] The general disposition of a device or link controller for establishing 

communications between host and client devices is shown in FIGS. 4 and 5. In FIG, 4 
and 5, a MDDI link controller 402 and 502 is show" installed in a host device 202 and a 
MKDI link coniroUcr 404 trnJ 504 i> shi, iu,i..ii:(.-..l in a diaiL device 204. As before, 
host 202 is connected lo a client 204 using a bi- directional communication channel 406 
comprising a series oL coaducturs. jib discussed Dciow, both the host and client link 
controllers can be maiiufscir!:-.-. ■ " -u imc u circuit using a bingle circuit design that 
can bn. set, adjustL-t] or i.>ni;^i;iii^riu t! m- u-spotid as either a host comroDer (driver) or a 
client coiiiiclloi- (receiver). "I'his provides for lower costs due to larger scale 
manufacturing of a single circuit device. 

[001271 In FIG.. 4, a USB host device 408: and a USB client device 41 0 am also shown 

for use in implementing Type U interface versions of the MDDI. Circuits and devices 
for implementing such functions are well known in the art, arid are not described an 
fmlher detail herein. 

[00128] In FIG. 5, a MDDI link controller 502 is shown installed in a host device 202' 

and a MDDI link controller 504 i.s shown installed in a client device 204'. As before, 
host 2G2' is connected to a client 204' using a bi-directional communication channel 506 
comprising a series of conductors. As discussed before, both the host and client link 
controllers can be manufactured using a single circuit design. 
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[00129] Signals passed between a host and a client, such as a display device, over the 

MDDI linlc, or the physical conductors used, are also iUustrated in FIGS. 4 and 5. As 
seen in FIGS. 4 and 5, the primary path or mechanism for transferring data through the 
MDDI uses data signals labeled as MDD]JDataO+/- and MDDI_Stb+/-. Each of these 
ai-e low voltage data signals that are transferred over a differential pair of wires in a 
cable. There is only one timaition on either the MDDLPataO pair or the MDDI_Stb 
pair for each bit sent over the interface. This is a voltage based transfer mechanism not 
current based, so static current consumption is near Jiero. The host drives the 
MDDI_Stb signfila to the client display. 

[00130] While data can flow in both the forward and reverse directions over the 

MDDI_Data pairs, that is, it is a bi-directional transfer path, the host is the master or 
controller of the data link. The MDDI_DataO and MDDI-Stb signal paths are operated 
in a differential mode to maximize' noise immunity. The data rate for signals on these 
lines is determined by the rate of the clock sent by the host, and is variable over a range 
of about 1 kbps up to 400 Mbps or more. 

[00131] The Type-n interface contains one additional data pair or conductors or paths- 
beyond that of the Type-I, referred to as MDDI_Datal+/-. The Type-El interface 
contains two additional data pairs or signal paths beyond that of the Type-II interface 
referred to as MDDI„Data2+/-, and MDDLData3+/-. The Type-IV interface contains 
four more data pairs or signal paths beyond that of she Type-Hi interface referred to as: 
MDDI data4+/--, MDDI„Data5H-/-, MDDLDala6+/-, and MDDI„Data7+/'-, 
u 1 * L "^L,! f tfb >' L mtula c conf gui -I lo' ^ i nt l «i s i li ^jower to the 
cliriif 01 1i isir^ ill. lien i ri h1 < M^inlid a^ RmDT„Pwr and 

MDDI„GT(d. 

[00132] A IvpL iti -t I'-^e ^vfe il / r me ih le toi the T\pe 1] umtiguratioii is 

the "'ll^Ol USH c ">niec* on or i s"^' pa*-*! 1 ne ^I'JDI I en lecj^n )mprises a 
secondary path for communication between a host and a client display. In certain 
applications it may be more advantageous to send certain information at a relatively low 
data rate between a host and client. Using the USB transfer link allows devices without 
an MDDI Link Controller that have a. USB host or limited host capability to 
conimunicate with an 'Mi3-Dl-compatible .client or display equipped with the Type-U 
interface. Examples of information that can be usefully transfen-ed over a USB 
interface to a display ^e: static bitmaps, digital audio streams, pointing device data, 
keyboard data, and control and status iriforraation. iPunctionality supported through the 
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USB interface can also be implemejited using the primary MDDI high-speed serial data 
path. While tJie data (see packets below) defined above may be sent over a USB type 
interface, the requirements for chaining data in the fonn of packets back-to-back do not 
apply tto such a. USB interface, neither does use of packets supporting MDDI Type 
haodoff. 

[00133] A summary of the signals passed between the host and client (display) over the 
MDDI link are iilugtrated in Table 1, below, in acecidance with the interface type. 

[00134] Table I 



Tvpe-1 


Type-II 


Tvpe-IH 


Tvpe-rV 


MDDLPwr/Gnd 


MDDI_Pwr/Gad 


MDDJ„Fwr/Gnd 


MDDLPwr/Gnd 


MDDI_Stb-iy- 


MDDLStb+/- 


. MDDLStbHh/- 


MDDLStb+/- 


MDDI_DataO+/- 


]VIDDUDataO+/- 


MP01_l)ataO+/- 


MDDI..DataO+/-- 




MDDU5atal+/- 


MDDLDataH-/- 


MDDiPatal+/~ 






MDDl_:Data2+/- 


MDDI„Data2+/- 


Type-U 




MDDIJData3+/- 


MDDLData3+/- 


MDDLPwr/Gnd 






MDDI_Data4+/- 


MDDLStb+/- 






MDDI_Data5+/- 


MDPLDataO+/- 






]S1DDI_Data6-f/- 


MDPLUSBh-/- 






MDDLData7+/- 



[00135] Cabling generally used to implement the above structure and operation is 
nominally on the order of 1.5 meters in length and contains three twisted pairs of 
conductors, each in turn being multi-strand 30 AWG wirc. A foil shield covering is 
wrapped or otherwise formed above the three twisted pairs, as an additional drain wire. 
The twisted pairs and shield drain conductor terminate in the display eonneotor with the 
shield connected to the shield for the display (client), and there is an insulating layer, 
covering the entire cable, as would be weE known in the art. The wires are paired as: 
MDDLGnd with MDDI„Pwr; MDDLStbH- with MDDI„Stb-; IttDDI_DataO+ with 
MDDLPataO-; MDDlJDatal+ with MDDI„Datal-; and so forth. The nominal cable 
diameter is on the order of 3.0 .mm with a nominal impedance of 85 ohms ±10%, and 
DC resistance nominaHy of 110 ohms per 1000 feet. The signal pi-opagation velocity 
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shqald be nominaHy 0.66c, with a maximum delay through the cable less than around 
8.0 nsec. 

D. Data Types and Rates 
[00136] To achieve a useful interface for a full range of user experiences and 

apphcations, the Mobile Digital Data Interface (MDDI) provides support for a variety of 
displays and display information, audio transducers, keyboards, pointing devices, and 
many other input devices that might be integrated into Of working in concert with a 
mobile display device, along with control information, and combinations thereof. The 
klDD interface is designed to be able to accomiaodate a variety of potential types: of 
streams of data traversing between the host and client in either the forward or reverse 
link diiections using a minimum number of cables or conductor. Both isochronous 
streams and asynchronous stream (updates) are supported. Many combinations of data 
types are possible as' long as the aggregate data rate is Jess than or equal to the 
maximum desired MDDI link rate. These could include, but are not limited to those 
items listed in Tables II andlli below. 



Transfening ftom Host to Client 


isochronous video data 


720x480, 12Ml:, 3(.>f/s 


-124,5 Mbps 


isochronous stereo audio data 


44.1kHz, I6bit, stereo 


~ 1.4 Mbps 


asyndhrcmou^^s gtaphics data 


800x600, 12bit, lOi/s, stereo 


-115.2 Mbps 


asynchronous control 


minimujn 


« 1.0 Mbps 


Table ni 


Tmnsferring froin Client to Host 




issochmiious voice data 


' 8 W ■ 


« 1.0 Mbps 


isochronous viueu dt-ua ; 61uxh1Iu, libit, i'H/t, 


'8.5 Mips 


asynchi-onous status, user mpL 


I, etc. i mimmum 


! 0 \hpi 1 



9] The interface is not fixed but extensible so that it can support the transfer of a 
variety of information "types" which includes user-defined data, for future system 
flexibility. Specific examples of data to be accommodated are; full-motion video, either 
in the form of full or partial screen bitmap fields or compressed video; static bitmaps at 
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low lates to consen'e power and reduce implementation ccets; PCM cjtr compressed 
audio data at a variety of resolutions or rates; pointing device position and selection, md 
tiset-definable data for capabilities yet to be defined. Such data may also be tiransfened 
aldiig with control or status infonnfltiofi to detect device capability or set operating 
parameters. 

[00140] The present invention advances the art for use in data transfers that include, but 
are not limited to, watching a movie (video display and audio), using a personal 
coimputer with limited personal viewing (graphics display, sometimes combined with 
video and audio), playing a video game on a PC, console, or personal device (motion 
graphics display, or synthetic video and audio), "surfing" the Internet, using devices in 
the fonri of a video phone (bi-directional low-rate video and audio), a camera for still 
digital pictures, or a camcorder for capturing digital video images, md for productivity 
■ enhancement or entertainment use with cell phones, smart phones, or PDAs. 

[00141J The mobile data interface as discussed below is presented in terms of providing 
large amounts of A-V type data over a communication or transfer link which is 
generally configured as a wire-line ox cable type link. However, it will be readily 
apparent that the signal structure, protocols, timing, or transfer mechanism could be 
adjusted to provide a link in the form of an oiJtical or wireless media, if it can sustain 
the desired le vel of data transfer. 

[00142] fli. >!f ! i 1 1 ]h a^e (CtHor 

the basic signal prolo 1 r t ^^^^ J i n., o < i o il i' n f'jan e to 

provide a synchroniz ^ Ict wmultaueoL.' I'-cu^uc k u dati> '-treams A d!^p!ay 

device can use this CO i or!- o ^ " ^ < 4 lov c 1 f ii ( " -( s 

channel efficiency by detie i > ih l > j I tl h i i 1 ikt On tlie 
other hand, a high CF late decitn i ic latei l> mi s i smallei eUstiL dila biitfL.r 
for audio samples. 1 le c"^ itc o' t c ^.c^'ci m%ei*i e inte tc.c" an t-j. b 
programmable and ma^ ce "-et at one of mir^ ah l mi v-^ )pi»iopi.aiC ^oi l"c 
isochronous sti-eains used in a particular application. That is, the C'F value is selected to 
best suit the given display device and host configuration, as desired, 

[00143] Tlie number of bytes generally required per common frame, which is adjustable 

or programmable, for isoclironous data steams that are most likely to be used with an 
application, such as for a head-mounted micro-display are shown in Table IV. 



wo 2004/110021 PCT/US2004/017579 



[00144] Table rV 



Common Frame Rate (CFR) = 1200 Bz 




X 


Y 


Bit 


Frame 
Rate 


Channel 


Rate 
(Mbps) 


Byte/ 
CER 


DVD Movie 


720 


480 


12 


30 


1 


124.4 


12960 


Stereo Graphics 


800 


600 


12 


10 


2 


115.2 


12000 


Cameocder 


640 


480 


12 


24 


1 


88.5 


9216 


CD Audio 


1 


1 


16 


44100 


2 


1.4 


147 


Voice 


1 


i 


8 


SOOO 


1 


0.1 


6.7 



[00145] FracticHial counts oif bytes per common frame are easily obtained using a simple 
programmable M/N counter structure. For example, a count of 26-2/3 bytes per CF is 
implemented by transfening 2 frames of 27 bytes each followed by one frame of 26 
bvtes. A smaller CF rate may be selected to produce an integer number ot b^vtes per CF. 
Ill) t a ^ciui 11 > ]K il^ii t iiiii til ipiL \l/^coiitaj fn Mie should 

r^qu L,^ aiea \smmi an mtegiated ciicuit chip or eieccioxsjc r-odu'e used to 
unplcmciit part or all of the mvcntion thaji the area needed for a larger aiidto sample 
FIFO buffer. 

[00146] An . >enp\-» opDl ation that illustrates tbi. i ' -t ( It im i i i 1 r 
xates -j-a d"t rvpcs . 1 j'^t" ■< ^ ^¥ ^ i^ > m ii a 

music \ideo piogi im Lsnc o b r i i p i d i lb --ut rr i f-t ihe 
I'.. K^oi !i 'h= \\„idi io r^t bLfij, md rougni} IIjc aufiin^ d L e ton^ 1 Ub a^-p ljl o<i 
r4.q \i c \if cn t !si i> <. jih infrequent graphics updates, and mixing ot the user's 
voice Vi'ith !.i stereo au<.li.o suream. 

[00147] It one i III t, a 11 1 11 i„ i t t. i (I Hj h n t.ath v_l will Lomibt ol 

92.160 bytes ot video content and Dbb b\tes ol audio content ibased on 147 16-bit 
samples, in stereo): over the forward link to the display device, and an average of 29.67 
(26-2/3) bytes of voice are sent back from a microphone to the mobile Karaoke 
machine. Asynchronous packets ai'e sent between the host and the display. This 
includes at most 768 bytes of graphics data (quarter-screen height), and less than about 
.200 bytes (several) bytes for miscellar.eous control .and status: commands. 

[00148J Table V, shows how data is allocated \vithin a Common Frame for the Kai-aoke 
■example. The total rate being used is selected to be about 225 Mbps.. A slightly higher 
rate of 226 Mbps allows about another 400 bytes of data per sub-fiame to be transferred 
which allows the use of occasional control and status messages, 
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[00149J TidjleV 



Element Rate 


Bytes/CF 


" IJ X 1 SO pbccia and 30 fps 


92160 


L.-.. it 1 1 D X 120pixels and 1 fps 


768 


CD Audio at 44.100 sps. stereo, i6-bit 


588 


Voice at 8,000 sps, mono, S-bit 


26.67 


.Suij-u.u.u; Htad^r 


19 


Reverse Link Overhead 


26.67-5-2*9+20 


Total Bytes/GF 


93626.33 


Total Rate (Mbps) 


234.7032 



III. High Rate Digits Data Interfiace System Architecture 
E. Link Layer 

[00150] Data transferred using the MDD interface high-speed serial data signals eoiisistis 
of a stream of time-multiplexed packets that are. linked one after the other. Even when a 
transffiitting device has no data to send, a MDDI linlc contfoller generally automatically 
sends lilier packets, thus, maintaining a stream of packets. The use of a simple, packet 
structure ensures reliable isodironou.s tiiiiing for video and audio signals or data 
Streams.. 

[00151] Groups of packets are contained within signal elernente or structures referred to 

as sub-frames, and groups of sub-ftames axe contained within signal elements or 
structures referred to as a media-frame. A sub-tifmie roiUoins one or more packets, 
depetiding on their respective size and data irancier uses, and a msdia- frame contains 
•one .more sub-frames. The largest sub-frame provided by the protocol employed by the 
present invention is on the order of 232-1 or 4,294,967,295 bytes, and the largest 
:inedia-frame size then becomes on the order of 216-1 or 65,335 sub-frames. 

[00152] A special header packet contains a unique identifier that appears at the beginning 

of each sub-frame, as is discussed below. That identifier is also used for acquiring the 
frame timing at the client device when communication between the host and client is 
initiated. Link timing acquisition is discussed in more detail below. 

[001S3] Typically, a display screen is updated once per media-frame when fuil-motion 

video is being -displayed. The display frame rate is the same as the media-frame rate. 
The linlc protocol supports fuU-motiion video over an entire display, or just a small 
region of full-motion vidm content surrounded by a static image, (fcpending on the 
desired application. In some low-power mobile applications, such as viewing web 
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pages or email, the display screen may only need to be updated occasionally. In those 
situations, it is advantageous to transmit a single sub-frame and then shut down or 
inactivate the link to minimize power consumption. The interface also supports effects 
such as stereo vision, and handles graphics primitives. 
[00154] Sub-frames exist to enable the transmission of high-priority packets on a 

periodic basis. This allows simultaneous isochronous stireams to co^exist with a 
jmnimal amount of data buffering. This is one advimtage the present invention provides 
to the display process, allowing multiple data streams (higJi spaed oommunication of 
video, voice, control, status, pointing device data, etc.) to essentially share a common 
chatmel. It transfers information using relatively few signals. It also enables display- 
technology-specific actions, to exist, such as horizontal sync pulses and blanking 
intervals for a CllT monitor. 

F. Link Controller 
[001,15] ihc AlDDl n i - uru actuitlr. i. siri 2a 

to be - ccrrol l> d •.^^ 11 o i l J n (1 il 1 ie 

recei' er'^ wbti li n u ^ t i * ■ • ■ 1 1'^ ss^i 4'- H m> 1, .sa '\t 
diffcicMtU' \vt d">ci^ piiu receivers, can be implemented ir 'he >javt d-g'ia! intt^g-ated 
circuit^ vu tlr I i« i jrfmlla \ b.g funcUonb 01 ph-i^v K 1. ( (PJ I <) are 
required "-o ji-lcnnttc i . . ."-c link controller The ho"*^ a id ci.cit 1 nk 
controllers contain very similar functions, with the exception of the display interface 
'\h'v'i C'-'iiU nb a t,v e imL'i ue loi hiik ijn UoruzaHoi Tifieioi^ ihe pre<ienr 
II '■/-Til 'a illmw li- 1 ! ! * i ir <'t- o 1 1 J I Im ucate a ■ijngle contiollei 
d -Ni I n Hi !i client, which can reduce 

manufacturing costs for the imk c-ontrolleis, as a whole. 

IV, Interface Link Protocol 

A. Frame structure 
[001.56] The signal protocol or frame structure used to implement the fomard iiiik 
communication for packet transfer is illustrated in HG. 6. As shown in FIG. 6, 
information or digital data is grouped into elements known as packets. Multiple packets 
me in tum grouped together to form what are referred to as a "sub-frame," and multiple 
sub-frames are in tum grouped together to form a "media" frame. To control the 
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fonrntitm of frames and transfer of sub-frames, each sub-frame begins with a specially 
predefined packet referred to as a Sub-frame Header Packet (SHP). 

[00157] The host device selects ttie data rate to be used for a given transfer. This nite 
can be changed dynamically by the host device based on both the maximum transfer 
capability of the host, or the data being retrieved from a source by the host, and the 
maximum capability of the display, or other device the data is being b'ansferred to. 

[00158] A recipient client device designed for, or capable of, working with the MDDI or 

inventive signal protocol is able to be queried by the host to determine the maximum, or 
curpsnt maximum, data transfer rate it can use, ot a default slower minimum rate may be 
used, as well as useable data types and features supported. This information could be 
transferred using a Display Capability Packet (DCP), as discussed further below. The 
client display device is capable of transferring data or communicadng with other 
devices using ac inTeriax .1 )>ie ^^^t' trd puninum data rate or within a rnxnimotn 
data rate range jfjd th:; J > < uui. i-,mg a data rate within this range to 
determine the full capabilities oi the client aeviccs. 

[00153] Other status mlorm u r d f nn^ Ihc n t a oi h bum ip and \nlco irame rate 

capabilities of the Jj*-! . , ^ i oe iidnbferred m a staluti packeL lo the lOfc' to -hrft tl'e 
host can configure the interface to be as efficient or optimal as practical, or desired 
within any system ctmsinnmK. 

[001601 The h si ' - . . f ru ) tlu j pi.!^ , U be 

transferred in trc pr^b^n ^^ib Ir j" v r ' "".c nob. t. iri I r.n,.kr A id s- b 'lluian 
to keep pace v 'h if e d ti-'iisnubbioa t-ae tn f^"-' fo' 'h Itim '1 h ii i ¥ h 
sub-frame bejfi i uiln , ^ h ndoi 'i > Mf < u nl iIk p i viuij> -^uo-fTanie 
contains a pak L t r. o il • ! i i tlj. Isil, Ihi' i ri. i.>u sab-frame 

In the case of a lack of room for d.j* i k.hi j .r' tt'? per se, a filler packet will most 
Mkely be the last packet in a :uh ti&irr. . ir„" ?r. I of a next previous sub-frame md 
before a sub-trame header packet. It is the task of the control operations in a host 
device to ensure that there is sufficient space remaining in a sub-frame for each packet 
to be transmitted within that sub-frame. At the same time, once a host device initiates 
the sending of a data packet, the host must be able to successfully complete a packet of 
that size within a frame without incurring a data under-run condition, 

[00161] In one aspect of embodiments, sub-frame transmission has two modes. One 
mode is a periodic sub-ftame mocte used to transmit live video and audio streams. In 
this mode, the Sub-frame length is defined as being ncai-zero. ITie second mode is an 
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asynchronous or non-periodic mode in which frames are used to provide bitmap data to 
a display device only when new information is availiible. This mode is defined by 
setting the sub-frame len^ to zero in the Sub-frame Header Paclcet. When using tlie 
periodic mode, sub-frame packet reception may commence when the display has 
synchronized to the forward link frame structure. This corresponds to the "in sync" 
stateis defined accrarding to the state diagram discussed below with respect to FIG. 49 or 
EIG. 63. In the asynchronous non-periodic sub-fimie mode, reception commences after 
the first Sub-fi:anie Header packet is received. 



B. Overall Packet Structure 
|;00162| Ine tcrirat or simctare ot packets used to formulate the signaling protocol 

implejT^ented oy ^be present invention are presented below, keeping in mind tha^ mc 
iTiteiface is eitenMok s id additi<">rtdl packet structuies l.-ii be -idded ..s dfbiicd The 
I ackets MC IdlK cu a;- <.n ui\i( mi lii i^\n ' paJvC 1\ Xb" in L'ti,ys otTiKit tunction 
m the .ntct.i:c. t'-.a: k., coain^i it- .r daia Ltizy l,..ir.!iicF Trerclorc. c:.cn rf^-.-vCt type 
dcncic p A '111 ;j f i.kt,"- ftui'ure for a given packc ^ h n • i-j^.' ir iranipuiaiing 
±c, p.i.l,' nd i.vM 1 .iii'i transferred. As will be readil> appt'jens sh- pi'tkctt n^ay 
'■^dve pre-^eV t h' h ii 't''^ have variable or dynamically diangeable 'exigihi depending 
on their resoriLUu '"V^ » The packets could also bear diffenng names hlthoagh the 



same function is ? 
acceptance into a stan^Luid 
configured as niuiti-cil <i- 



Ihe b>tes or b^rte values 
>r 16-bit) unsigned mtege- 



n'ci.h are changed dunng 
m the vmouB packets are 
^ n ulju '^f tlic packets 
ij ij-i-L oid^i, hown itt 
sidered valid is also noted. 



ith whether or not tliey are used lor a Type-U interface. 



[00163] Table VI 



Packet Name 


Packet 

...Type 


Valid HI Direction 


Forward 


Reverse 




Sub-frame Efeadbr Packet 


255. 






X 


Filler Packet 


■0 


X 


X 




Video Stream Pacltet 


1 


X 






Audio Stream Packet 


2 


X 


X 




Reserved Stream Packets 


3.^55 








User-Defined Stream Packets 


56-63 


X 


X 


X 
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Color Map Packet 


64 


X 






Reverse Link. EneapsulatiOH Packet 


65 


X 






Display Capability Packst 


66 




X 


X 




67 




X 


X 


Packet Nsinie 


Packet 
Type 


Valid in Direction 


Forward 


Reverse 


Type-U 


.l|ig.!B§..5£yiE — — 


68 










69 


X 






.DisplEy K.cc|U6st and Status P£ic-kGt 


70 




X 


X 


}3it JBlocic [rBiisfcr Psxiikst 


71 


X 




X 


Hltniap A.rsa Pill P^jk&t 


72 


X 




X 


Bitmap PattetTi Fill Packet 


73 








Communication Link Data Channel 
Pflckct 


74 


X 






-iinerrace lyp&xiauuoii Kcxjucai irdt-s.cL 


75 


x 






Intsxfscs- Xyps Acknowledge Piickst 


76 




X 




Ferfonn Type Handoff Packet 


77 


X 






Forward Audio Channel Enable Packet 


78 


X 




X 


Reverse Audio Sample Rate Packet 


79 


X 




X 


Digital Content Protection Overhead 

Packet ■ 


80 


X 


X 


X 


Transparent Color Enable Packet 


81 


X 






Round Ij-jp Delay Measurement Packet 


82 


X 






Forwai-d Link Skew Calibration Packet 


83 









[001641 Packets have a common basic structure or overall set of minimum fields 
comprising a Packet Length field, a Packet Type field. Data Bytes field(s), aiid a CRC 
field, wliich is illustrated in PIG. 7. As shown in FIG, 7, the Packet. Length field 
contains information, in the form of a multi-bit or -bj'te value, that specifies the total 
number of bits in the packet, or its length between the packet length field and tihe CRC 
field. In one embodiment, the packet length field contains a 16-bit or 2-byte wide, 
unsigned integer, that specifies the packet length. The Packet Type field is another 
muiti-bit field which designates the type of information that is contained within the 
packet. In an exemplary embodiment, this is an 8-bit or 1-byte wide value, in the fonn 
of an 8-bit unsigned integer, and specifies such data types as display capabilities, 
handoff, video or audio streams, status, and l=;o forth. 

[0D165:] A third field is the. Data Bjaes field, which contains the bits or data being 

transferred or sent between the host arad client devices as part of that packet. The 
format of the data is defined specifically for each packet typs according to the specific 
type of data being transferred, and may be separated into a series of additional fields, 
each with its own format lequiremente. That is, each packet type will have a defined 
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format for this portion or fieid. The last field is the CRC field which contains the results 
of a 16-bit cyclic redundancy check calculated over the Data Bytes, Packet Type, and 
Packet Length fields, which is used to confinn the integrity of the infcamation in the 
packet In other words, calculated over the entire packet except for the CRC field itself. 
The client generally keeps a total count of the CRC eixors detected, and reports this 
count back to the host in the Display Request and Status Packet (see further below). 
[00166] During tniitsfer of the packets, fields axe transmitted starting with the Least 

Sigfiificant Bit (LSB) first and ending with the Most Sijgoificant Bit (MSB) transmitted 
last. Parameters that are more than one byte in length are transmitted using the least 
:significant byte first, which results in the same bit transmission pattern being used tbr a 
parameter greater than 8 bits in length, as is used for a shorter parameter where the LSB 
is transmitted first. The data on the MDDI_DataO signal path is aligned with bit '0' of 
bytes transmitted on the interface in any of the modes, Type-I, Type-II, Type-HI, or 

[00167] When n:£iiiru]rjina data for displays, the diit:. for LirrLVi of pixels are 

tratiamitled by rows firf.:. rhcsi .jr;ir:rv", d~ i~ rru'Ttirr-i h' den: ir the cIccLrom^cs arts. 
.In other words, all pixels iha; appciir ts -i-Mix um ':i bii msip ric 'ransmii'.ed in 
order with the left-most pixel transmitted first and the light-most pixel transmitted last. 
After fhe right -rno-.t ni^ei ...i i 's transmitted tlicn the next pixel in the sequence is 
the ter'-mos,l piK.e! --t s ■ ■ • fow. Rows of pixeh urc fc-neriilly tn;nsmii!.cU in 
order irom top to boiio:"^ ak rrioii displays, although other cuntigurations can be 
accommuduted as ne^ti^d. furthermore, in handling bitmaps, ilie cDUvealiontJ 
approach, which is followed here, is to define a reference point by labeling the upper- 
left c(.fti:t of a >A. .1,-1- i- H-rtH .-I u-\ ■! 'j ' Tiic X and Y coordinates used to 
define 01 djlfiuuijie p./^i.ion m llie bitmap iniucasc iu value as one approaches the 
light and bottom of the bitmap, respectively. The first row and first column start with 
an index value of zero. 

C. Packet Definitions 

1. Sub-frame Header Packet 
[001,68] The sub-frame header packet is the first packet of every sub-Jxame, and has a 
basic stracture as illustrated in FIG. 8. As can be seen in HG. S, this type of packet is 
structured to have Packet Length, Packet Type, Unique Word, Sub-Frame Length, 
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Protocol Version, Sub-Frame Count, and Media-ftame Count fields, generally in that 
order. Tliis type of packet is generally identified as a Type 255 (Oxff hexadecimal) 
packet and uses a pre-seleeted fixed length of 17 bytes. 

[001691 While the Packet Type field uses a 1 byte value, the Unique Word field uses a 3 
bjte value. The 4-byte combination of these two fields together forms a 32-bit unique 
word with good autocon-eiation. In an exemplary embodiment, the actual imique word 
is Os005a3bfr where the lower 8 bits are transmitted first as the Packet Type, and the 
most isignificant 24 bits arc transmitted afterward. 

[00170J The Sub-frame Lengtli field contains 4 bytes of information that specifies the 
number of b^tes per sub-frame. Tlie length of this field may be set equal to zei'o to 
indicate that only one sub-frame will be transmitted by the host before the link is shut 
down into an idle state. The value in this field can be djinamicaliy changed "on-the-fly" 
when transitioning from one sub-frame to the next. This capability is useful in order to 
make minor timing adjustments in the s>nc pulses for accommodating isochronous data 
.streams. If the CRC of the Sub-frame Header packet is not valid then the link controller 
should use the Sub-fraine Length of the previous known-gewd Sub-Erame Header packet ■ 
.• to estimate the length of die ciurent sub-frame. 

[00171] The Protocol Version field contains 2 bytes that specify the protocol version 
used by the host. The Protoco! Version fie'd is set to '0' to specify the first or current 
. vmion of the protocol as being used,. Thta vshir. will change over time as new versions 
are created. The Sub-frame Count lieid contaius 2 bytes that specify a sequence number 
that indicates the number of sub-iiames that have been transmitted since the beginning 
of the media-frmie. The first sub-fi'ame of the media-irame has a Sub-frame Count of 
zero. The last srib-frrj lic; of the media-frame has a value of n-1, where n is the number 
of sub-frames per media-frame. Note that if tlie Sub-frame Length is set equal to zero 
(indicating a non-periodic sub*-frame) then the Sub-frame count must also be set equal 
to zero. 

[00172] The Media-frame Count field contains 3 bytes that specify a sequence munber 
that indicates the number of media-frames that have been transmitted since the 
beginning of the present media item or data being transferred. The first mecUa-frmne of 
.a media item has a Media-frame Count of zero. The Media-frame Count increments, 
just prior to the first sub-frame of each media-fnune and wraps back to zero after the 
maximum Media-frame Count (for example, media-frame number 224-1 = 16,777,215) 
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is used. The Media-frame Count value may be reset generally at any time by the Host 
to suit the needs of an end application. 



2. Filler Packet 

[00173] A filler packet is a packet that is transferred to, or from, a client device when no 

other information is avaflable to be sent on either the forwaid or reverse Hnk. It is 
recommended that filler packets have a minimum length in order to allow maximum 
flfexibility in sending other packets when required. At the vety end of a sub-frame or a 
reverse link encapsulation packet (see below), a link controller sets the size of the filler 
packet to fill the remaining space to maintain packet integrity. 

[00174] The format and contents of a Filler Packet are shown in FIG. 9. As shown in 

FlO. 9, this type of packet is structured to have Packet Length, Packet Type, Filler 
Bvtes, iiid CRr KdcT- Thts '^vpe of packet is generally idenufKcl i i ^pc 0 which 
iiidi itm 11 till 1 I ■> L t\o. ii-L liu i> V 1 i I 1 t H 1 ilct [$>ti.'; tiJd. coinpnsc a 
\ 3! I able nunbci of all zcio bi o t o i l t.i u r Ik the denied leiT-nh 

liiL. imllc Ttillei patlctLmim-^ ro -\t ^ 11 ih ill Til ii ]i.ik(t».oii tof 
only the packet length, packet type, and CRC, and uses a pre-selected fixed length of 3 
bytes. : 

3. Video Stream Packet 

[00175] Video Stream Packets carry video data ■ p J l ii I i i uf 
a display device. The size of this region may be as small as a single pi'iel or m large as 
the entire display. There mav be an aimosl urilumitd luinibei ot stieams d1spld■^ed 
simultaneons1>. Ion >c( lu «» il ( k^i Ca.1 u^uii icd i..- dui^l^v a 

stream is conr.uacd v i ! i i » ^. i i Piikc ^or lit ir tli:; MCeo !ilTC.Am 

packet (Video Data 1 Oijia'- Dcvcupt^! _, '^h^wn m IK I'; <-ee i r F -j 0 h"- 
type of packet is strun-iied lo tia' s Packet Len^l*^ (T b^i'-^'^ P < "^t""* v iH f • i ' 
Descriptor, Display Attributes, X Left Edge, Y Top Edge, X Right Edge, Y Bottom 
Edge, X and Y Start. Pixel Cotmt, Parameter CRC, Pixel Data, and CRC fields. This 
type of packet is generally identified as a Type 1, which is indicated in the 1 byte tj^pe 
field, 

[00176] The common frame concept discussed above is an effective vtfay to minimize the 

audio buffer size and decrease latency. However, for video data it may be necessary to 
spread the pixels of one video frame across multiple Video^ Stream Packets within a 
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media-frame. It is also vsry likely that fee pixels in a single Viifeo Stream Packet will 
not exactly correspond to a perfect rectangular window on the display. For the 
exemplaiy video frame rate of 30 frames pea: second, tiiere are 3CKI sub-frames per 
sec(Mid, which resulte in 10 siiWramfis per media-fcahie. If thisre are 480 cows of pixels 
in each frame, each Video Stream Packet in each sub-frame will contain 48 rows of 
pixels. In other situations, the Video Stream Packet might not contain an integer 
number of rows of pixels. 'ITiis is true for oth^^^ video frame sizes where the number of 
sub'frames per media-lrame does not divide evfenly iiito thei aumbcr of rows (also 
known as video lines) per video frame. Each Victeo Stream Packet generally must 
contain an integer number of pixels, even though it might not contain an integer number 
of rows of pixels. This is important if pixels are more than one byte each, or if they Eire 
in a packed format as shown in FIG. 12. 

[001771 "lie u)np<jt ;>ii'i co>-iteri«- employed for realiHng (he (ipiiMtion (>f an exemplary 

Viueo rj'ii.i Dev jjpioi li^li .s I, I 11. ,Ka,.h('vo .^re sIkami iit iUCiS. lla-lUl IjiJ'UiS. 
1 ia-1 L.1, ;}u; V.ilri I . ii iJ. . .rr >. r,c!d crntarns i ,->\rc;, m t^c ioi-mol a i6 bit 
unsigned intc<^ ,- ih ,r ^ra i'.ii- sK- '<■- c c p \d n P x :l luiu in \m present 
stream ik the p-^^cir pj.-Lci. Ii is possible mai ciflcictii k'' "=.'iim"i p, t ..'■(■n rrit-y us© 
diffcrcn: pi.Kei data foi-nats, that is, use a difif'ir.j:rt ^'iluc ^'m V'lhr ' -m Format 
Descriptor, a"d s 'ii'^ft'lt •<> '•■ir \>-> '.r-^....-. -.i i! 'i-i.i.iv) ,,i c' .•■u-i <[-i JaU format 
on-the-fly. llv V,,\o r>j, , i , , , i - , .r-rl toi-nat tor the present 

f acirct cniy v^hich dees not smplj tnttt c^jiistant, toimat vviii continue to be usee lor ihe 
lifetime of a particular video stream. 

[0017S] FIGS. 11a through lid I'lu'^-frnc <w tre Vide<i Data Format Descriptor is 
coded. As used in thei,(. figin i jl j! I 1 li t, then bits [15:13] are equal to 
'000', as shown in Flf f 11« tit ■/< < > i >. i tf an array of monochrome 

pixels where the nunil t-r v I "-il- pt,r vi-^J u dch icd b% b*'~ 3 through 0 of the Video 
Data Format Descripior • Lid Silii 11 through 4 are set to iSero in this situation, v-fhen 
bits [15:i3] are instead equal Lo '001', as shown in:FIG. lib, then the video data consists 
of an array of color pixels that each specify a color through a color map. In this 
situation, bits 5 ttoougli 0 of the Video Data Format Descriptor word define the number 
of bits per pixel, and bits 11 through 6 ai-e set equal to zero. When bits [15:13] are, 
instead equal to '010'., as shown in FIG. 1 1c, then the video data consists of an airuy of 
color pixels where the number of bits per pixel of red is defined by bits 11 through 8, 
the number of bits per pixel of gi^een is defined by bits 7 through 4, and the numb^ of 
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bits per pixel of bine is defined by bits 3 through 0. In this situation, the total number of 
bits in each pixel is the sum of the number of bits used for red, green, and blue. 

[00179J However, when bits [15:13] are instead equal to 'Oil', as shown in FIG. lid, 
then the video data consists of an array of video data irt 4:2:2 format with luminance and 
chrominance infonnation, where the number of bits per pixel of luminance (Y) is 
defined by bits 1 1 through 8, the number of bits of fte Cr component is defined by bits 
7 through 4, and the number of bits of the Cb component is defined by bits 3 through 0. 
The total number of bite in each pixel is the sum of the number of bits used for red, 
green, and blue. The Cr and Cb components are sent at half the rate as Y, In additicai, 
the video samples in the Pbcel Data poition of this packet ai-e organized as follows: Yn, 
Cm, Cbn, Yn-il, irni, Cmi2 Lbn!2, Yc wbs'-^ L ana Lbn jie as^ocMted 

with Yn and ^ I'+l and Cin+2 and Cbn+2 die issr^u I'eo v'"n ^2 ^rd \r-^3, ar>d so 
on. If there au i \ <-dd nuiTiber of pi \.^Is in a i (X P l Edge - X Left Edge + 1) in 
the present s&e in ncn ihi. ( i \ Ju ki c-p ndtuj'U \Y<. last pixel m t^h row will be 
followed by the Y value ot the nrsi ptxcl oi the next row. 

[00180] For ah to.ir U it ii I U ii u i - k 1 

specifies whether or ro i>- < i « o i i p 1 <• 

A viilue of '0' m Lhi f -Id nd i- i f each pi\d and each coloi v. Jthiii cilIi pixel m 
the Pixel Dat. tie! i'- - " ^ ^(b).! lonli^ -i. v^ilu- uf 

T indicates tl * t.i'' - ' i *'i P ^-l )i ns packed 

up against the prei it u" Ji\t:,' ^i^ itfn « p. ^zl iCaM"g ■n^ unused t f 

[00181] The first pixel in the first video stream packet of a media frame for a particular 

display window will go into the upper left comer of the stream window defined by an X 
Left Edge and a Y Top Edge, and the next pixel received is placed in the next pixel 
location in the same row, and so on. In this first packet of a media frame, the X start 
value will usually be equal to X Left Edge, and Y stai't value will usually be equal to Y 
Top Edge. In subsequent packets corresponding to the smiie screen window, the X and 
Y start values will, usually be set to the pixel location in the screen window that would 
nomally follow after the last pixel sent in the Video Stream Packet that was transmitted 
in the previous sub-frame. 

4, Audio Stream Packet 
[00182] The audio stteam packets carry audio data to be played through the audio system 

of the display, or for a stand alone audio presentation device. Different audio data 
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streams jnay be allocated for separate audio channels in a sound system, for example: 
left-front, right-front, tenter, left-rear, and right-rear, depending on the type of audio 
system being used. A fiill ccHiiplement of audio channels is i>ro\'ided for headsets that 
contain enhanced Bpatial-aeoustic signal processing. The format of Audio Stajeam 
Packets are illustrated in FIG. 13. As shown in FIG. 13, this type of packet is structured 
to have Pacloet Ixngth, P^ket Type, Audio Chaniciel ID, Audio Sample Corat, Bits Per 
Sample and Packing, Audio Sample Rate, Parameter CRC, Digital Audio Data, and 
Audio Data CRC fields. Li one eiubodiment, this type of padket is generally identified 
as a Type 2 packet, 

[00183] The Bits Per Sample arid Packing field contains 1 byte in the form of an S'^bit 

unsigned integer that specifies the packing format of audio data. The format generally 
employed is for Bits 4 through 0 to define the number of bits per PCM audio sample. 
Bit 5 then specifies whether or not the Digital Audio Data samples are packed. The 
difference between packed and byte-aligned audio samples is illustrated in FIG. 14, A 
value of '0' indicates that each PCM aiidio sample in the Digital Audio Data field is 
byte-aligned with an MDDl interface byte boundary, and a value of T indicates that 
each successive PCM mt^o sample is packed up against the previoos audiu saraple. 
This bit is effective only -wbeii the value del'ined in bits 4 through 0 (the number of bits: 
per PCM audio sample) is not a multiple of eight. Bits 7 through 6 are reserved for 
futiHe use and are generally set at a value of zero. 

5. Reserved Stream Packets 

[00184] In one embodiment, packet types 3 through 55 ii. r ^-n * . u for stream packets to 

be defined for -use in future versions 1-1 \ ,i u . i i t |ni.l«i.N protocols, as desired for 
various applications encountc lui Agfun, tins 1.5 part of r/.f.ldng the MDD interface 
more flexible and useful in the face of ever changing teschnology and system designs as 

compared to other techniques,. 

6. User-Defined Sti'eaoi- Packets 

[00185] Eight data stream types, known as Types 56 through 63, are reserved for use in 

p(ix)prietary applications that may be defined by equipment manufacturers for use with a 
MDDI link. These are known as User-defined Stream Packets. The video stream 
packets carry video data to update (or not) a rectangular region of tlie display. The 
definition of the stream parameters md data for these packet types is left to the specific 
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equipment maHufactuiiers seeking their use. The fomiat of the user-dejftned stream 
packets is Oliistrated in FIG. 15. As shown in HG. 15, this type of packet is structttred 
to have Packet Length (2 bytes), Packet Type, SU'eam ID number. Stream Parameters, 
Parameter CRC, Stieam Data, and Stream Data CRC fields. 

7. Color Map Packets 

[00186] The color map packets specify the contents of a color map look-up table used to 

present colora for a display. Some applications may require a color map that is larger 
than the amount of data that can be transmitted in a single packet. In these cases, 
multiple Color Map packets may be transferred, each with a different subset of the color 
map by using the offset and length fields described below. The format of the Color 
Map packet is illustrated in FIG. 16. As shown in FIG. 16, this type, of packet is 
structured to have Packet Length, Packet Type, Color Map Data Size, Color Map 
Offset, Parameter CRC, Color Map Data, and Data CRC fields. This lype of packet is 
generally identified as a Type 64 packet. 

8. Reverse Link Encapsulaliuo Packets 

[00187] In mi exemplary ■embodiment, data is transferred in the reverse direction using a 

RoA - T a F I. 1 n i i> ' 'T- 1 ' i ■ . Lt.et k -,ei ' cn ' f-c MDDI link 

in ii HI 11.11 ■, I ('nth n d 'ic W i packet so 

tiirt. pui'vtt^ Id) Ik I t i'lo ^oniut o* tb^ Reverse Link 

Encapsuiation pacvct ' A"- ^'h'^wi ir Ho 1/ 'hi t\ po of packet 

Is "Jtmc-'ir^J n ""a ^ ^ ^' ' ^ )P- i^'^st^i,'^ L"ijs. Hags, Tuni-Around 

ier Pl-u iL tL i HP oimJ i Fevt-isf ijti pa kets, and Turn-Around 2 
fields. This tvpc of packet is generally identified as a Type 65 packet. 

[00188] The MDDI link controller behaves in a special manner while sending a Reverse 

Link Encapsulation Packet. The >1DD interface has a strobe signal that is always 
driven by the host. The host behaves as if it were transmitting a zero for each bit of the 
Turn-Around and Reverse Data Packets portions of the Reverse Link Encapsnlation 
packet. The host toggles a MDDI_Strobe signal at each hit boundary during the two 
tum-around times and during the time allocated for reverse data packets. (This is the 
same behavior as if it were transmitting all-aero data.) The host disables its MDDI data 
sigt»al line drivers during the time period specified by Titrn-Arotind 1, and the client re- 
enables its line drivers during the Driver Re-enable field following the time period 
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specified by Tum-Around 2 field. The display reads the Tum-Around Length 
parameter and diives the data signals toward the host immediately after the last bit in 
the Tum-Around 1 field. The display uses the Packet Length and Tum-Around Length 
patameters to know the \&\g&i of time it has availaibk to send packets eo the host The 
client may send filler packets or drive the data lines to a zero state when it h^ no data to 
send to the host. If the data lines are driven to zero, the host interprets this as a packet 
with a zero length (not a valid length) and the host does not accept any more packets 
from the dheilt for this duration of the current Reverse Linlf Encapsulation Packet. 

[001S9] The client display drives the MDDI data lines to the zero level for at least one 

reverse link clock period before the start of the Turn Around 2 field. This keeps the 
data lines in a deterministic state during the Turn Around 2 time period. If the client has 
.no more packets to send, it may even disable the data lines after driving thera to a zero 
i3vc> bpcausc ih;; nil ■enialip'ir In j-, lesifctors (discuf-pcd eKevvbwe') Veep ihs liiitd hnei> <ft a 
zero level for the remainder ol the Reverse Data Packets field. 

[00190J ','rc •Acvzi<^i. ' i k : - .1 It. 'p'jji R::qjci,t £.-nJ Sl,,JiU l\ ; t n'ay 

be used to mtorm the host ot the number ot bvtes me display needs m the Itevcnsc Link 
Encapyjlati ii la.M o .i ■ ■ ■ - !'t >>, ~re ros' at'-e^nr't^ 'U- 'he 
^equs^sl bv (is.i ..m • t ! > ibcr of b)!!,' ii> the ReNcjse L'lik E'-capsuUtion 

Packet. The host may send more than one Reverse Link Encapsulation Packet in a sub- 
frame. The display may send a Display Request and Status Packet at almost any time, 
. and the host will interpret the Reverse Link Request parameter as the total number of 
bytes requested in one sub-frame. 

[00191] A host tieedt, 1a l,-n>^ the capaujlitv ot tLe (LapL) iclient) it is communicating 

with i.i cfdzv to co.-itigtisc the host-tc cii'^pla, hnk :n an generally optimum or desired 
maiitie" it is recommenced ihat a chsplav send a Display Capability Packet to the host 
.after forwai'd link syncbromzation is acquired. The tiansmission of such a packet is 
considered required when requested by the host using the Reverse Link Flags in the 
Reverse. link Encapsulation Packet The format of the Display Capability packet is 
illustrated in FIG. 18. As shown in FIG. 18, this type of packet is stmcmred to have 
Packet .Length, Packet Type,, Protocol Version, Min Protocol Version, Bitmap Wi.dth, 
Bitmap Height, Monochrome CapabiUty, Color Map Capability, RGB Capability, Y Cr 
Cb CapabiUty, Display Feature Capability, Data Rate Capability, Frame Rate 
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Capability, Audio Buffer Depth, Audio Stream Capability, Audio Rate Capability, Min 
Sub-firanae rate, and CRC fields. In an exemplary embodiment, this type of packet is 
generally identified as a Type 66 packet. 

10. Keyboard Data Packets 

[00192] A keyboai-d data packet is used to send keyboard data from the client device to 

the host. A wireless (or wired) keyboard may be used in conjunction with various 
■displays or audio devieies, including, but not limited to, a head mounted video 
display/audio presentation device. The Keyboard Data Packet relays keyboard data 
received from one of several known keyboard-like devices to the host. This packet can 
al50 be used on the forward link to send data to the keyboard. The format of a 
Keyboard Data Packet is shown in MG. 19, and contains a variable number of bjtes of 
information fn)iTi or for a keyboard. As shown in FIG. 19, this type of packet is 
structured to have Packet Length., Pacjcet Type, Keyboard Data, and CRC fields. Here, 
tliis tj-ps of packet is generally identified as a Type 67 packet. 

11. Pointing Device Data Packets 

[00193] A pointing device data packet is used to send position infoimadon from a 
wireless mouse or other pointing device from the display to the host. Data can also be 
sent to the pointing device on the forward link using this packet. An exemplary format 
of a Pointing Device Data Packet is shown in FIG. 20, and contains a variable number 
of bytes of information from or for a pointing device. As shown in HG. 20, this type of 
packet is structured to have Packet Length, Packet Type, Pointing Device Data, and 
CRC fields. In an exemplarj' embodiment, tMs type of packet is generally identified as 
a Type 6S packet in the l-byte type field. 

12. Link Shutdown Packets 

[00194] A Link Shutdown Packet Is sent from the host to the client display to indicate 

that the MDDI data and strobe will be shut down and go into a low-power consumption 
"hibernation" state. This packet is useful to shut down the link .and conserve power 
after sialic bitmaps are sent from a mobile communication device to the display, or 
when there is no further information to transfer from a host to a client for the time 
being. Normal operation is resumed when the host sends packets again. The first 
packet sent after hibernation is a sub-frame header packet. ITie format of a Disjday 
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Status Packet is shown in FIG. 21, As shown in FIG. 21, this type of packet is 

struGtured to have Packet Length, Packet Type, and CRC fields. In one embodiment, 
this type of packet is generally identified as a Type 69 packet in the 1-byte type field, 
and uses a pre-selected fixed length of 3 bytes. 
[00195] Iii the low-poweir hibernation state, the MDDI jJata driver is disabled into a 
high-impedance state, and the MDDI_Data signals are pulled to a logic zero state using 
a high-impedance bias network that can be o-verdriven by the display. The strobe signal 
used l»' Ai'-iiLi.t: tc- i l-'j.'c zero level in the hibernation state to minimize 
powei coifeuiiipiitHi. Eitboi ihe .'Rjst or client may cause the MDDI link to "wake up" 
■ A-,tr rht- li.herr.afion state as dc5c;ribed elsewhere, which is a key advance for and 
advantage of the present invention.- 

13 Display Request and Stat its Paekots 

[00196] The host needs a small amoiou of iTif<Hjnat)on from the display so it can 

configure the host-lo-v]ispl;>y Imk i.. r:^. v ,.: > --jainum rnnnncr. it is: lecjmmended 
that the display send one D spJay Status Packet - i'l. hi>^: i;h ^ub-trame. 'Lhe display 
should send tliis packet a.i the first packet in the Rcvcri^e Linlc Encapsulation Packet to 
ensure that it is delivered reliably to the host. Tlie format of a Display Status Packet is 
<ibov p ir F^f"' As shown m FIG 22, this*-'' . l-« > jaored to have Packet 
I rj'i ki.1 , Reverse Link Request f ^ n < ud CRC fields. This 

L^fP^ ul piv.kci f k ucrali% identified as a 1 ype ' paukct in the i byte type field, and 
uses a pre- selected fixed letiatti ot 8 bytes. 

[D019 '1 Ihe '^'"-....i e ' ' ^ < n n >(Mn om tne host of the miinher of 

byres the displav n----<. n li F'-xp l i T i ati on Packet to send data back to 
the host. The host should attempt to grant the request bv allocating at least that number 
btt '5 ir the Rc ci=t 1 luk \ uc r ul Oi P cLct Fi e ho'^' n-.,-' ^end more than one 
lloT-cr"^ L nt tica^t-uiat on Pacl<et in a sub frame in ordc to a ,.ommodat8 data. The 
cli;nt nia\ -jerd a U '•p'a^ Request and Status Pd( \t:' i' ii> ' I'm- and the host will 
irtL p 'h-^- P--' e se I irfc P'='qn'=',t paiaraeter as the lotal numbtar ol bytes requested in 
one sub-frame, AdcUtional details and specific exainples of how reverse link data is sent 
back to the host are shown below. 
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14. Bit Block Transfer Packets 

[00198] The Bit Block Transfer Packet provides a means to scroll regions of the display 

in any direction. Displays that have this capability will report the capability in bit 0 <rf 
the Display Feature Capability Indicators field of the Display Capability Packet. The 
format of a Bit Block Transfer Paclcet is shown in HG. 23. As shown in HG. 23, this 
type of packet is structured to have Packet Length, Packet Type, Upper Left X Value, 
Upper Left Y Value, Window Width, Window Height, Wuidow X Movement, Window 
Y Movement, and CRC fields. This type of packet is generally identified as a Type 71 
packet, and uses a pre-sclected fixed length of 15 bytes. 

[00199] The fields are used to specify the X and Y values of the coordinate of the upper 

left corner of the window to be moved, the width and height of the window to be 
moved, and the number of pixels that the window is to be moved horizontally, and 
vertically, respectively. Positive values for the latter two fields cause the window to be 
'moved to the right, and down, and negative values cause movement to the left and up, 
. respectively.. 

15. Bitmap Area Fill Packets 

[002GO] The Bitmap Area Fill Packet provides a means to easily initialize a region of the 

display to a single color. Dispiays that have this capabihty will report the capabihty in 
bit 1 of the Display Feature Capability indicators fjield of the Display Capability Packet, 
■j 'he fomiat of a Bitmap Area Fill Packet is shown in FIG. 24. As shown in FIG. 24, this 
type of packet is structured to have Packet Length, Packet Type, Upper Left X Value, 
. Upper Left Y Value, Window Width, Window Height, Data Fomat Descriptor, Pixel 
Area Fill Value, and CRC fields. This typ& of packet is generally identified as a Type 
72 packet in the 1-byte type field, and uses a pre-selected fixed length of 17 bytes. 

16. Bitmap Pattern Fill Packets 

[00201] The Bitmap Pattern Fill Packet provides a means to easily initialize a region of 

the display to a pre-selected pattern. Displays that have this capability will report the 
.capability in bit 2 of the Display Feature Capability Indicators field of the Display 
Capability Packet. The upper left comer of the fill pattern is aligned with the tipper left 
comer of the window to be filled. If the window to be filled is wider or taller than the 
fill pattern, tiien the pattern may repeated horizontally or vertically a number of times to 
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tliJ the window. The right or bottom of the last repeated pattern is truncated as 
necessary, if the window is smaller than Uie fill pattern, then the right side or bottom of 
the fill pattern may be truncated to fit the window. 
[00202] The fomat of a Bitmftp Pattern Fill Packet is shown in FIG. 25. As shown in 

FIG. 25, this type of packet is stmctured to have Packet Length, Packet Type, Upper 
Left X Value, Upper Left Y Value, Window Width, Window Height, Pattern Widlh, 
Pattern Height, Data Format Descriptor^ Parameter CRC, Pattern Pixel Data, and Pixel 
Data CRC fieRs. This type of packet is generally identified as a Type 73 packet in the 
1-byte type field. 

17, Communication Link Data Cbaimel Packets 

[00203] The Cormnunication Link Data Channel Packet provides a means for a display 

with high-ievel computing capability, ^v.ch us h PDA, u) cc>mnioriiuriie \vitli ;3 ^\'irrlr,ss 
toiiEii.-fiver sucii ;fs. ^ cc'l plic^N. .>i ..;ii-,s tlaiH purl dex'icc. Ir. iiJKS siuuuion, ihe 
MDDI link is acting as a coiivenierit high-speed interface betvi-'een the communication 
device and the computme; dc\icc with the mobile display, where this packet transports 
data at a "Data Link Layer of an L'pcruiing syttan lor Ihe device. r»ir exanijic, this 
packer cou'.d be used if a web browser, email client, or an entice PDA were built into a 
rriohils di.'piay. Displays tinit have W<\< cipybi'dy \vi)l r.-rpor' the capabijity m bit 3 of 
IhcDis-piiiv ['cai-urc Cdpi-5il.t: li ii ,t ii. i {1.. !>,,. I, ^ i'npability Packet. 

[002041 'f 'he format of a Communicaiion Link Data Channel t'acket is stiov/n in FIG. 26. 

A?, shown in FiC. 26, ihis type of packet is structured to has'e Pacicel LeagLh, Packet 
Type, Parameter CRC, Communication Link Data, and Communication Data CRC 
fields. This type of packet is generally identified as a Type 74 packet in the type field. 

18. Interface Type Handoff Eeqiiest Packets 

1002051 The Interface Type Handoff Request Packet enables the host to request that the 
client OF display shift from an existing or current mode to the Type-I (serial), Type-II (2- 
bit parallel),. Type-Ill {4-bit parallel), or Type-IV (S-blt parallel) modes. Before the host 
requests a particular mode, it should confirm that the display is capable of operating in 
the desired mode by examining bits 6 and 7 of the Display Feature Capability Indicators 
field of the Display Capability Packet. The format of a Interface Type Handoff Request 
Packet is shown in FIG. 27. As sliown in FfG. 27, this type of packet is structured to 
have Packet Length, Packet Type, Interface Type, and CRC fields. This type of packet 
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is generally identified as a Type 75 packet, and uses a pre-selected fixed length of 4 
bytes. 

1 9. Interface Type Acknowledge Packets 

[00206] The Merface Type Acknowledge Packet is sent by the display to contlmi receipt 
of the Interface Type Ilandoff Pactet. The requested mode. Type-] (serial), Type-tl (2- 
bit parallel), Typc-III (4-bit parallel), or Type-IV (8-Mt parallel) mode, is echoed back 
to ' 1- 1 'ius pac keL The format of a Interface Type Acknowledge 

PecLlI ih bhovMi 11 riG 28 As bhown in FIG. 2S, this type of packet is stmcfuied to 
; SVC Tfirkf * 1 ;np;th, Pcc\&t I vpc. Interface Type, and CRC fields. This type of packet 
is generally identified as a Type 76 packet, and uses a pre-selected fixed lengtii of 4 
bytes. 

20. . Perform Type Ilandoff Packets 

[00207] ■ The Perfonn Type Handoff Packet is a means for the host to command the 
display to handoff to the mode specified in this packet. This is to be the same mode that 
was previously requested and acknowledged by the Interface Type Handoff Rec{uest 
Packet and Interface Tjpe Acknowledge Packet. The host and display should switch to 
the agreed upon mode after this packet is sent. The display may lose and re-gidn link 
synchronization during the mode change. The format of a Petform T>pe Handoff 
Packet is shown in FIG. 29. As shown in FIG. 29, this tj-pe of packet is structured to 
have Packet Length, Packet Type, Packet Type, and CRC fields. This type of packet is 
generally identified as a Type 77 packet in the 1-byte type field, and oses a pre-selected 
fixed length of 4 bytes. 

21. Forward Audio Channel Enable Packets 

[0020S] This packet allows the host to enable or disable audio channels in the display. 

This capability is useful so the display (client) can power off audio amplifiers or similar 
■circuit elements to save power wlien there is no audio to be output by the host This is 
significantly more difficult lo iinpicmcnl imislicir y Si.iiply using the presence or 
.absence of audio streams as an indicator. The default state when the display system is 
powered-.up is that all audio channels are enabled. The format of a Forward Audio 
Channel Enable Packet is shown in FIG. 30. As shown in FIG 30, this type of packet is 
structured to have Packet Length, Packet Type, Audio Channel Enable Mask, and CRC 
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fields, 'rhis type of paclwt is generally identified as a Type 78 packet in the 1 -byte type 
field, md uses a pre-selected fixed length of 4 byJes , 

22. Reverse Audio Sample Bat£ Packets 

[00209] This packet allows the host to enable or disable the reveise-link audio channel, 
and to set the audio data sample rate of this stream. The host elects a sample mte that 
is defined to be valid in the Display Capability Packet. Jf the host selects an invalid 
samplei tats then the display will not send an audio stream to the host. The host may 
disable the reverse-link audio stream by setting the sample rate to 255. The default state 
. assumed when the display system is initially powered-np or connected is with the 
, reverse-link audio stream disabled. The format of a Reverse Audio Sample Rate Packet 
is shown in FIG. 31. As .shown in FIG. 31, this type of packet is structured to have 
Packet Length, Packet Type, Audio Sample Rate, and CRC fields. This type of packet 
is generally identified as a Type 79 packet, and uses a pre-selected fixed len^ of 4 
bytes. 

33. Digital Content Protection Overhead Paclsets 
[00210] This packet allows the host and a display to exchange messages related to the 

digital content protection method being used. Presently two types of content protection 
are contemplated, Digital Transmission Content RrotectioTs (DTCP), or High-bandwidth 
Digital Content Protection System (HDCP), with room i-eserved for future alternative 
protection scheme designations. The method being used is specified by a Content 
Protection Type parameter in this packet. The formal of a Digital Content Protectioti 
Overhead Packet is shown in FIG, 32. As shown in FIG. 32, this type of packet is 
structured to have Packet Length, Packet Type, Content Protection Type, Content 
Protection Overhead Messages, and CRC fields. This type of packet is ^.nerally 
identified as a Type 80 packet. 

24. Transparent Color Enable Packets 
[00211] The Transparent Color Enable Packet is used to specify which color is 

tramparenl: in a display and to enable or disable the use of a transparent color for 
displaying Images. Displays that have this capability will report that capability in bit 4 
of the Display Feature Capability Indicators field of the Display Capability Piicket. 
When a pixel with the value for transparent color is vraitten to the bitmap, the color does 
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not change from the previous value. The format of a, Transparent Color Enable Packet 
is. shown in HG, 33. As shown in FIG. 33, this type of packet is structuied to have 
Packet Length, Packet Type, Transparent Color Enable, Data Format Descriptor, 
Transparent Pixel Value, and CRC fields. This type of packet is generally identified a& 
a Type 81 packet in the 1-byte type field, and uses a pre-^lected fixed ieagth of 10 
b5rtes. 

2S. Ronnd Trip Delay Measurement Packed 
[002] ^] T\\f ~-' II ~- li ~' Uy Measurement Packet is used to measure the, i-iop;.s.rtior. 

delay i-uru tW, hoa r.i a c]u-nt GJi splay) plus the Dcli.-v Uotn tnc clieni fdsFpiay) back to 
thr host. 'I his mea'-,iircmjrir tnharently includes the dclavs ±at exist m the line drivers 
andicccivcrs, and an inrerconnect sub-system i'^l3 meLitui'^raent is used to set ihe "jm 
arouvd delav a^^ iQvzih'c hnk li'te 'Ji"'«n! ]V)iPtp*"i'^'^ n\ tlii^ TJc-veTsc Limk Epcipbfj'alion 
P-ick-r tlH><;n ib<^<l gonc[dli> .^b.At' Tin-- n, kr-i ,v n ]<;dul vUien the XiDDl L.ik is 
•running at the maximum speed intended tor a particular application. Ihe MDDI_Stb • 
sign^al behaves a."; though all zero data i$ hzme, sent dunng the toilowing fields: All 
Zerc. both '.j.^id ' ir^. and the Measurement Penod. Tnis causes IvlDDLSib to 
toggle at. halt tlie data rale so it can be used as periodic clock in the display during the 
Measuremerre Period. 

[00213J The format of a of Rout..] ! up l\ . , \1( i ..iun« -i Pvkcr -.imin m FIG. 34. 

As shown m FIG. 34, this type of packet is structured to have i'acket Length, Packet 
Tv^pe, i-'araniKter CRC. All Zero, Guai'd Time 1. J'.ieaiUieniL.'nl Peii-x ' " n ji i 2, 

[0021^1] TIk ti.iiEiii; t . I turn i^kc picict. dui<i- the Ri-i!nd Tap Del.u U". . n z. . nt 

Packet are illustrated in FIG. 35. In HG. 35, the host transmits the Round Trip Delay 
Measurement Packet, shown by the presence of the Paran^eter CRC and Strobe 
Alignment fields followed by the All Zero and Guaid Time 1 fields. A delay 3502 
occurs before the packet reaches the client display device or processing circuitry. As 
the display receives the packet, it transmits the Oxff, Osff, 0x0 pattern as precisely as 
practical at the beginning of the Measurement Period as deteimined by the display. The 
actual time the display begins to transmit this sequence is delayed from the beginning of 
the Measurement Pedod from the point of view of the host. The amount of this delay is 
substantially the tune it takes for the packet to propagate through the line drivers and 
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veceivets and the intercotmect subsystem. A sirnikir araotint Of delay 3504 is incurred 
for the pattern to propagate ftom tjie display back to the host. 
[00215] Iti order to accurately determine the round trip delay time for signals traversing 
to and from the client, the host covmts the number of bit tinae periods occurring after the 
start of the Measurement Period until tiie beginning of tlie Oxff, Oxff, 0x0 sequence is 
detected upon arrival. This information is used to determine the iKoount of time for a 
round tip signal to pass from the host to fiie cOient and back again. Then, about one half 
of this amount is attributed to a delay created for the one way passage of a signal to the 
client 

[00216J The display disables iis line drivers substantially immediately after sending the 
last bit of the Oxff, Oxff, OxG pattern. Guard Time 2 allows time for the display's line 
drivers to go completely to the high-irnpedance state before the host liansmits tlie 
Packet Length of the next packet The hibernation puil-up and puil-down resistors (see 
FIG, 42) ensure that the MDDIJJata signals m held at a valid low level in the intervals 
where the line drivers ajie disabled in both the host and display. 



26. Forward Link Skew CalibratioB Packet 

[00217] The Forward link Skew Calibration Packet allows a client or Display to 
calibrate itself for differences in the propagation delay of the MDDI„Data signals with 
respect to the MDD.I_Stb si^al, Witliout delay skew compensation, the maximum data 
rate is general^ v biuitid to 'u-ouni ff> ik)U un t ^<.i ■•iiiduot! n\ t'l <>( nr!->«, 

Generally, this packet lb unh senUihi i I i 1 i l.i*, i Uk-,^ mUgiutdtr irdtc 
of around 50 Mbp^ or lover \'ter v^n j a h [)^J tu cdiibiate the display, the data 
rate may be stepped I! J ' ^ e i£ jcnon iu^h dunng the skew 

calibration process i]i> -j ^ >> • • > > • > , a :vi >■ r>i "if Iv 'jeii'-d v n.h 
could <;.iiis(; ilu oi'dv sU w i ( ii ^ nsn n- -eiuiij/ to I'-p oh b> nioie ll'. i ui^ 1 I 'ii 
resulting in ennneous Jat<i ciorkiii - > i njlu si Jju rate typo oi inteifaco ut gUoifi,t 
possible Iiiterfas^c I'vpe is sclccica piiur to tLndsnz the Forward Link Skew Cahfaration 
Packet so that a^i exibung data .irj iiDr^^icd 

[00218] The foniidt of a Forward Link Skfc\s C alieratien PatKet i** n in FLO 56 As 

shown in FIG. 56, this type of packet is structured to have Packet Length i'Z bytes). 
Packet Type, Parameter CRC, Calibration Data Sequence, and CRC fields. This t}'pe of 
packet is generally identified as a Type S3 packet in the type field, and has a pre- 
selected length of 515. 
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D. Packet CRC 

[00219] The CRC fields appear at the end of the packets and sometimes after certain 
mtjre critical parameters in a packet that may have a signiflcantly large data field, and 
thus, an increase likelihood of errors during transfer. In packets that have two CRC 
fields, the CRC generator, when only one is used, is le-initialized after the first CRC so 
that the CRC computations following a long data field are not affected by the 
parameters at the beginning of the packet. 

[00220] In an exemplary embodiment, the polynomial used for the CRC calculatioii is 

Iciiown as the CRC-46, or X16 + X15 + X2 + XO. A sample implementation of a CRC 
generator and checker 3600 useful for implementing the invention is shown, in EIG. 36. 
In FIG. 36, a CRC register 3602 is initialized to a value of 0x0001 just prior to transfer 
of the firet bit of a packet which is input on the Tx_MDDI_Data_Befoie_CRC line, then 
the bytes of the packet are shifted into the register starting with the LSB first. Note that 
the register bit numbers in this figure correspond to the order of the polynomial being 
used, and not the bit positions used by the MDDI. It is more efficient to shift the CRC 
register in a single direction, aad this results in having CRC bit 15 appear in bit position 
0 of the MDDI CRC field, and CRC register bit 14 in MDDI CRC field bit position 1, 
and so forth until MDDI bit position 14 is reached. 

[00221] As an example, if the packet contents for the Display Kcuucsl: and vSwUis Packets 

are: 0x07, 0x46, 0x000400, 0x00 (or represented as a sequence of bytes as: 0x07, 0x00. 
0x46, 0x00, 0x04, 0x00, QxOO), and are submitted using the inputs of the multiplexors 
3604 and 3606, and NAM) gate 3608, the resulting CRC output on the 
Tx_MDDIJ)ata„With_CRC line is OxOeal (or represented as a sequence , as Gxal, 
OxOe). 

[00222] When CRC generator and checker 3600 is configured as a CRC checker, the 
CRC that is received on the Rx3iDDI„Data Une is input to multiplexor 3604 and 
.NAND gate 3608, and is compared bit by bit with the value found in the CRC register 
using NOR gate 3610, exclusive-OR (XOR) gate 3612, and AND gate 3614. If there 
axe any errors, as o!itput by AND gate 3614, tlie CRC is incremented once for every 
packet that contains a CRC error :by connecting the output of gate 3614 to the input of 
register 3602. Note that the example circuit shown in the diagram of FIG. 36 can output 
more than one CRC error signal within a given CE[ECK„CRC_NOW window (see FIG. 
STB). Therefore, the CRC error counter generally only counts the first CRC error 
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instance within interval where CHECK^CRCjSfOW is active. If configiaed as a 
CRC generator the CRC is clocked out of the CKC registes: at the time coinciding •with 
the end of the packet. 

[00223] The dming for tiie input and output signals, and the enabling signals, is 
iilustrated graphically in FIGS. 37 A and 37B. The generation of a CRC and 
transmission of a packet of data are shown in HG. 37A with the state (0 or I) of the 
<fen_Re&et, Check„GRCJSfow, Generate_CRC_Now, and Sending31DDI_Data 
signals, along with the T3L>IDDLJ>ataJBefojne„CRC and Tx_MDDI„Data„With_CRC 
signals. The reception of a packet of data and chazking of the CRC vsQue aiie shown in 
FIG. 37B, with the state of the Gon_Reset, Check_CRC_Now, Generate_CRC_Now, 
and Sending_MDDIJData signals, along with the Rx_MDDI_Data and CRC error 
signals. 

E. Error Code Overload for Packet CRC 

[00224] ■r'!5-ni- (li-'ly eara nr.clcets and CRC ai'e being transferred between the host and 

clienl, tJnr i-- ut error codes being accommodated. The only enm is a loss of 
synchKmization,. Otherwise, one has to wait for iJie link to timeout from, a Sack of a 
good dau (ninsfcr path, or pipeline and then reset the link and proceed. Unfortunately, 
this If, time ^ m t'nr.u,'^ ir.A "-.omewhat inefficient. 

[00225] Foi v-c "1 'T - etr-l- \iimejit, anew technique has been developed in which the 
CRC portion of packeis is used to transfer error code iafonnation. This is generally 
•shown in the over view of FIG. 65, and in more detail in FIGS. 66A, 668^ and 67. That 
is, one or more error codes are generated by the processors or devices handling the data 
transfer which indicate specific predefined errors or flaws that might occur within the 
comniunication processing or link. When an eiTor is encountered, that the appropriate 
.error code is generated and transferred using the bits for tlie CRC of a packet That is, 
the CRC value is overloaded, or ovetwiiUen, with the desired error code, or some other 
pre-selected value to .represent the preseiuje of uii error, which can be detected .on the 
receiving end by an en-or roonilor or checker that monitors the values of tli© CRC field. 
For those cases in which the enw code matches the CRC value for some nsason, the 
compliment of the error is transferEed to prevent confusion. 

[00226] In one embodiment, to provide a robust .error warning and detection system, the 

error code may be transferred several times, using a series of packets, generally all, that 
are transferred or sent after the error has been detected. This occurs until the point at 
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whieh the condition creating the error is cleared from the s>^tein, at which point the 
regular CRC bits are transfeiTed without overloading by another value. 

[00227] This technique of overloading the CRC value provides a much quicker response 

to system errors while using a minimal amount of fcxtra bits or fields. 

[00228] As shown in ,FIG. 66, a CRC overwriting mechanism or apparatus 6600 is 
shown using an error detector or detections means 6602, which can form part of other 
circuitiy previously described or known, detects the presence or existence of errors 
withiii the eommuiiicalioh link or process^ An error code generator or means 6604, 
which can be formed as part of other circuitry or use techniques such as look up tables 
to store pre-selected eixor messages, generates one or more error codes to indicate 
specific predefined errors or flaws that have beers detected as occuning. It is readily 
understood that devices 6602 and 6604 cm ha formed as a single circuit or device as 
desired,, or as pait of a programmed i^eqiience of steps for other knowii processors and 
elements, 

[00229J A CRC value coraparal-.i oi <i, r.".rirr. iicans 6606 is shown for checking to 

see if the selected en-or code or code- ,:rc t^. .lu-.h. the CRC value being traiisfcrrcd. 
If that is the case then z code compiniicni gjnz-rmor or generation means or device is 
used tO' provide the compliment of the eiTor codes as to not be mistaken as the original 
CRC t It (> 1. 1' ' .f . . ( 1 fht- dH-'cii on scheme. An error code 

^l'< h i' ti i ■ n 1 s Ict ts the error code or val.ue it 

IS desired to insert . )\c t h„ c . ^ compliments as appropriate. An 
CTOT code v..^L o ^ - m t means 6612 is a device that 

receives the data stream, packets, and the desired codes to be inserted and overwrites the 
correspondhig or appropiialje CRC values, in order to transfer the desired error codes to 
a receiving device. 

[00230] As mentioned, the error code may be transferred several times, using a series of 

packets, so the over-writer 6612 may utilize memory storage elements in order to 
maintain copies of the codes during processing or recall these codes from previous 
dements or other known storage locations which can be used to store or hold their 
values as needed, or as desired. 

[00231] The general processing the overwriting mechanism of FIG. 66 is implementing 

is shown in additional detail in FIGS, 67A and 67B. In 67A an enw, one or more, is 
detected in step 6702 in the coimnunieation data or process and an error cotfc is selected 
in step 6704 to indicate this condition. At the same time, or at an appropriate point, the 
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CRC value to be replaced is checked in a step 6706, and compared to the desired qrror 
code in step 6708. The result of this compaiison, as discussed earlier, is a determination 
as to whether or not the desired code, or other repreSCTtative values, will be the same as 
the CRC value present. If this is the ease, then processing pmceeds to a step 6712 
where the compliment, car in some cases another representative value, as desired, is 
selected as the code to insert. One it has been deteimined what error codes or values 
are to be inserted in steps 6710 and 6714, that appropriate code is selected for inseortion. 
These steps ate illustrated as separate for purposes of clarity but generally represent a 
single choice based on the output of the step 6708 decision. Finally, in step 6716 the 
appropriate values arc overwritten in the CRC location for transfer with the packets 
being targeted by the process. 
[00232] On the packet reception side, as shown in FIG. 67B, the packet CRC values are 
being monitored in a step 6722. Generally, the CRC values are being monitored by one 
or more pj-ocesses within the system to determine if an error in data transfer has 
occunrd and whether or not to request a retransmission of the packet or paclcets, or to 
inhibit further operations and so forth, some of v/hich is discussed above. As part of 
such monitoring the information cmi also be used to compare values to known or 
preselected ciTor codes, or representative values and detect tiie presence of errors. 
Alternatively, a separate cut" J ■ . <>: ess md iiionilC'r can be implemented. If a 
code appears to be present i - \- .>i -.rl'iir.viw notrd in step 6724 for further 
processing. A determination can t)c made m stcr 6726 as to whether or not this is the 
actual code or a compliment, in which case an adajiiouu! step 6728 is used to translate 
the value to the desired code value. In either case the resulting extracted code, 
tioinp: I . ^ 1 cs are tiien used to detect what error has occurred 

form the ti-ansrxiitted code m step 5730. 

V. Liiik Restait from Hiberaatioii 
[00233] When the host restarts tlie forward link from a hibernation state it drives 

MDDLData to a logic one state for about 150 jjsec and then activates MDDI_Stb and 
simultaneously drives MDDIJData to a logic zero slate for 50 |isec, and then starts 
fcffwaid link traffic by sending a sub-frame header packet. This generally allows bits 
contentions to be resolved before the sub-&ame header packet is sent by providing 
enough settling time between signals. 
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[00234] When the client, here a display, needs data or communication from the host it 
drives the MDDI_DataO line to a logic one state for around 70 pec, although other 
periods can be iised as desired, md then disables the driver by placing it in a high- 
impedance state. Tltis action causes the host to start or restart data traffic on the 
foi-ward litik (208) aiid to poll the client for its status. The host must detect the presence 
of the request pulse within 50 jii^c and then begin the startup sequence of drivhig 
MDDI_DataO to logic one for 150 usee and to logic zero for 50 jjisec. The display 
should not send a service request ■ - ! ■ >' ■ ".' " _n-rjO iu the logic one state 
for more than 50 usee. The nature of selection of the times and tolerances of time 
intervals related to the hibernation processing and start up sequence are discussed 
further below. 

[00235] An example of the processing steps for a typical service request event 3800 with 
no contention is illustrated in FIG. 38, Where the events are labeled for convenience in 
illustration using the letters A, B, C, D, E, F, and G. The process commences at point A 
when the host sends a Link Shutdown Packet to the client device to inform it that the 
link will transition to a low-power hibernation state. In a next step, the host enters the 
low-power hibernation state by disabling the MDDLDataO driver and setting the 
MDDLStb driver to a logic zero, as shown at point B. MDDJJ>ataO is ckivcii to a zero 
level by a high-impedance bias network. Aftea: some period of time, the client sends a 
service request pulse to the host by driving MDDIJDataO to a logic one level as seen at 
point C. The host stUl asserts the zero level using the high^mpedance bias network, but 
the driver in the client forces the line to a logic one level. Within SO }lsec, the host 
recognizes the service request pulse, and asserts a logic one level on MDDIJDataO by 
eii^littg its driver, as seen at point D. The client then ceases from attempting to assert 
the smice request pulse, and the client places its driver into a high-impedance state, as 
seeft at poitit E. The hast drives MDDLDataO to a logic zero levesl for 50 j-isec, as 
shown at point P, and also begins to generate MDDI_Stb in a manner eonsistent with 
the logic zeaa level on MDDLDataO. After asserting JyCDDLDataO to a zero level and 
driving MDDLStb for 50 fjsec, the hosthegins to transmit data on tlie forward link by 
sending a Sub-frame Header Packet, as shown at point G. 

[002361 A similar example is illustrated in FIG. 39 where a sesfvice request is asserted 
after the link restart sequence has begun, and the events ace again labeled using the 
lett^ A, B, C, D, E, P, and G. This represents a worst case scenario where a request 
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pulse or signal fronir ilie client comes closest to corruptiBg the Sub-frame Header Packet. 
The process commences at point A when the host again sends a link Shutdown Packet 
to the client device to inform it that the linlt vyill transition to a low-pow^r hibernation 
state. In a next step, the liost enters the low-powet hibeination state by disabling the 
MDDLDataO drive* and setting the MDDL-Stb driver to a logic zero, as shown at point 
B. As before, MDDI„DataO is driven to a zero level by a high-impedanee bias network. 
After a period of 'time, the host begms the link restart sequence by driving MDDLDataO 
;o a iocic one ' > ^ > li 

hnk restart sequence b^uP" tl e .lif ic^ ■ ai^n s XlDbLDaiati lui d (luititujii ol 70 
ULCL, tec i t -'"O 1. D Th •, hip,)c:i ■■ because 'he u-bpia^ in^ tu ccl k q! l s v 
ircm the ir^v J'^d '-^if-b "(i i.-o^inize thit the Imst bti> -hc^h tl.t \ml. u-^twil 

sequcr< e '^be 'hp"t ihen i wscs HlUinpLmy lo hi^-^rv 111- seix ice u q^int ^uUc, Jtid the 
client places its driver into a high-impedance stale, as seen at point E. The. host 
continues to drive MDDLDataO to a logic one level. The host drives MDDLDataO to a 
logic zero level for 50 \isec, as shown at point F, and also begins to generate Mr>DI_Stb 
in a manner consistent with the logic zero level on MDDI„DataO. After asserting 
MDDI„DataO to a zero level, and driving MDDI_Stb for 50 [isec, the host begins to 
transmit data on the forward link by sending a Sub-frame Header Packet, as shown at 
point G. 

[00237] Froin the above discussion, one sees that tbe prior solution involved having the 
host go through two states »s pairt of a wafceup sequence. For the first state, the host 
drives His JvlDDL-DataO signal high for 150 (is, and then drives the MDDLPataO signal 
low for 50us while activating the MDDI„Stb line, and then begins to transmit MDDI 
packets. This prosKsss works well to advance the state of the art in terms of data rates 
achievable using the MDXnl apparatus and methods. However, as stated earlier, moiie 
speed in terms of reduced response time to conditions or the ability to more quickly 
select the next step or process, or the ability to simplify processing or elements, are 
always in demand. 

[00238] Applicaixts havis diiscovered a new inventive approach to wafce-up processing 
and timing in which the host uses a clock cycle based timing for the signal toggjing. In 
this configuration, the host starts tog;^ng MDDI_Stb from 0 to 10 jjsec after the host 
diiveis the MDDLDataO signal high at the beginning of the wake^up sequence, and does 
not wait until the signal is driven low. During a wake-up sequence, the host toggles 
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MDDLStb as though the MDDIJlataO signal were always at a logic-zero level. This 
effectively removes the concept of time from the client side, and the host changes from 
the prior 150 [is and 50 periods for the first two stat^, to 150 clock cycles and 50 
clock cycles, for these peribds. 
[00239] The hoist now becoiMes responsible for driving that dau line high, and williin 10 
clock cycles starting to transmit a strobe signal as if the data line was zero. After the 
host has driven the data line high for 150 clock cycles, the host drives the data line low 
for 50 clock cycles while continuing to transmit the strobe signal. After it has 
completed both of these processes, the iiost can begin to transmit the first sub-frame 
header packet. 

[00240] On the client side, the client implementation can now use the generated clock to 

calculate the number of clock cycles that Lhe data line is first high, and then low. The 
number of clock cycles that need to occur in both the data line driven high state is 150 
and data line driven low state is SO, This means that for a proper wakeup sequence, the 
.-Kit il Ik I It t^ wOunt at least 150 conur 1 n -I ci v'cles of the data line being 
high ti)llu\vcd by at least 50 continu u ^ t 1 cyt t ot the data line being low. Once 
t.1e=et\\oi- nJi n e net rl < ( i for the unique word of the 
li -I su" ft an II 1 1 M >, ( return the counters to an 

nit: 3 =t e n ' II [ il 1 Mi ::ontinuous clock cycles of 

^Cl-i Hfb-l gh > 

[,00241j A I Ik Ik miLiiiUi o f . v. i n r i ost based wakeup from 

fibcn^ti^n 1 \er -inula, to tic n tial , ir^ ip ^ i t,\^L.,j that the clock rate is not 
forced to l i j-- ui'-cassi-d f-u'-^ rate can be set to 

resume at whatever previous rate was mthe- \ i i tu untiunication link went into 
hibernation. If the host begins UHiismissiou -A .> --'u ,U, .i^n.-d ,is flc;,cribed above, the 
client should be able to again count at least 150 continuous clock cycles of the data line 
being high, followed by at least 50 continuous clock cycles of the data line being low- 
Once these two conditions have been met, the client can begin the search for the unique 
word. 

[00242] A client implementation of the invention for client based wakeup from 

hibernation is similar to the host based wakeup except that it starts by having the client 
driving the data line. The client can asynchronou.sly drive tiie data line without a clock 
to wake up die host device. Once the host recognizes that the data line is being driven 
high by the client, it can begin its wakelip sequence. The client can count the number of 
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clock cycles getiBrated by the host starting or during its wakeup process. Once the 
client counts 70 continuous clock eycies of the data being high, it can stop driving the 
data line liigli. At this poiTit, the host should already be driving the data line high as 
well The client can then count another 80 continuous clock cycles of the data line 
being higli to reach the 150 clock cycles of the data line being high, and can then look 
for 50 clock cycles of the data line being low. Once these three conditions have been 
met the client can begin to look for the unique word. 

[00243] An advantage of this new implementation of wake-up processing is tliat it 
removes the need for a time measuring device. Whether this is an oscillator, or 
capacitor discharge circuit, or other such ioiown devices, the client no longer needs such 
external devices to determine the start up conditions. ITiis saves money and circuit area 
when implementing controllers, countere, and so forth on a client device board. While 
this may not be as advantageous to the client, for the host, this technique should also 
potentially simplify the host in temis of very high density logic .(VHDL) being used, for 

core circuitry T'v [>o r - "si "i" '-mu 'h. Ja a n-j tlrcb^ -ns^ tr.e wakcup 

notification .I'll n.. t ... .! i ^ ... i,, f,!\t n" t rd ."ircuitty will 

needtobcr.i ^ in t . iw.-.l \,, \^ . la iigfoi a host based wdc^up. 

[00244J The nii niber or cycles or clock periods used are exemplary and other periods can 
beusedasv''! ^ .'^-.■l-<*h f>",e -lilb.' tr t'-r 

[00245J An J . ■ • jt i v i u 

removes the ik < a Im \ ,w c a.^dbu mj, neMte Ys iiethe> tni, ««• ju i tJl itnr or 
capacitor disc h,i. . 1 . . . . < ^ i ^r.own d'-viu thetiient lio^t < r- ii- d, 
extssTial device", to iL . i . . i\ i Uu'i hy i.- i An ors ihiS '^a^c^ inunc} r i ; > n hi , u h 
^^h^n implcnur. ir.2 .intrj. c'=? ..v untv rs. c.u. fo tnr h ui .i ..Kent dc .'i.'-e boanS Whilo 
this may not be as, advantageous to the client, tor the host, this, technique should also 
p Si'. Iv Mt ii«hfj ibo ho^t in ii:- jt ■>! V CI' *iiiii d.-n^iii" m'ZiC (VHDLi hei ip u-etl :or 

notification and measurement source will also be lower since no extemai circuitry will 

need to be running for the core elements to be waiting for a host based wakeup. 
I00246J To clarify and illustrate the operation of this new technique, the timing of 

MDDI_DataO, MDDI_Stb, .and various operations relative to the clock cycles are shown 

.in FIGS. 58A, 68B, and 68G. 
[00247] An example of the processing steps for a typical Host-initiated Wake-up with no 

contention is illustrated in FIG. 68A, where the events are again labeled for convenience 
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in illustration using the letters A, B, C, D, E, F, mid G. The process cornmences at pcant 
A when the host sends a Link Shutdown Packet to the client device to infonn, it that the 
hnk V III luu) mnn to a low-jjowt-i iKbemation state. In a next step, point B, the host 
toggles MDDI_Stb for about 64 cyckks (or as desired for system design) to allow 
processing hy sIk di'^ni fo H . ompleted piior to stopping MDDLStb from toggling, 
which <itop-; t . „ . .r the client device. The host also initially sets 

MDDIJDataOf ^ ^ ^ <-cn disable* the MDDUDataO output in the range 

of 16 to 48 cycles ^"iput disable propagatioil delays) after the 

TRC It nT=iy he Jr i i i higli -speed reeeivera for MDDI_DataO and 
^7DDL "tl II 'h c In ii ni a iuA power state some time after the 48 cycles after the 
CM snJ pijc t- H 1.- J ■. t" (C ) 
[00248] I 'iL. h ^ kw power inbernation state at point or step C, by disabling 

the KiL'Dl i)adi> 11 d ^iDUl "-tb dnveih and placing a host controller in a low power 
MbemDti'-n svd c t'ne - <n iisu sJ ht. IvlT)DI_Stb driver to a logic-zeio level (using a 
I-igh- iV'cdiu^. t. a. ..UHo! c) , 1 vii n fibrillin dcsir^a 

[00249] Aftci J.OU1C pcuod irc h =t . luriccs -hL inil resCirl ^qu' nee at point 

D, bv enabling \j1 M . ' d r ^ ipt" l^'^'^t d^- ^e-^ 

MDDI DatiO lo a 't» >• •■ - l-^^t i« i> n .g a- t 

should take ku il i' il II '•>■' »ri-,>K 
waits aroui d isXi i!aji-.'>Yij)> - .« o.sei.iiiUis ' u-- kd before 

driving pulses on MMDJ_Stb 1 h^s allows the client t ^ i^n c 

[00250] With the host drivers er.bled and ^^L^L'! ^ i i i logic u-^e 

level, the host begins to toggle MDDI_Stb f n I i u t 1 0 ArnrT_^Sib cycles, as 
seen at point E. The host drives MDDLDataU to a logic zero level tor iO cycles, as 
shown at point F, and the client begins to look for She Sab-frarae Header Packet after 
IvIDDLDataO is at a logjc-zero level for 40 MDDLSlb cycl^. The host begins to 
transmit data on the forward link by sending a Sub-frame Header PacJoet, as shown at 
point G. 

[OffiSl] An example of the processing steps for a typical Client-iiiitiated Wake-up with 

no contention is illustrated in FIG. 68B, where the events are again labeled for 
convenience ia illustration using the letters A, B, C, D, E, F, G, H, and I As before, the 
prdcess cornmences at point A when the host sends a link Shutdown Packet to infomi 
the client tliat the link will transition to the low power state. 
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[00252] At point B, the host toggles MDDI_.Stb for about 64 cycles (or as desired for 

system design) to allow processing by the client to be completed prioi' to stopping 
MDDI_Stb from toggling, which stops the recovered clwk in the client device. The 
host also initially sets MDDI_DalaO to a logic-zero level and then disables the 
MDKLDataO output ki the range of 16 to 48 cycles {generally iocluding output disable 
propagation delays) after the CRC. It may be desirable to place high-speed receivers for 
MDDIJDataO and MDDIJStb in the client in a low power state some time after the 48 
cycles after the CRC and prior to the riext stage (C), 

[00253] The host enters the low-power hibemation state at point or step C, by disabling 

the MDDLDataO and MDDI„Stb drivers and placing a host controller in a low power 
hibernation state. One can also set the MDDIJStb driver to a logic-zero level (using a 
high -impedance bias network) or to continue toggling during hibemation, as: desired. 
The client is also in a low power level hibemation state. 

[00254] After some peiiod of time, the ciietit commences the link restart sequence at 

point D, by enabling the MDDI_Stb receiver, and also enabling an offset in the 
MDDI.Stb receiver to guarantee the state of the received version of MDDI„,Stb is a 
logic-zero level in the client before the host enables its MDDI_Slb driver. It .may be 
desirable for the client to enable the offset slightly aliead of enabling the receiver to 
ensure the reception of a valid differential signal and inliibit erroneous signals, as 
desired. The Client enables the MDDIJDataO driver while driving the MDDIJDataO 
line to a logic one level 

[00255] \Mthin noout i n".c" - " ' - . tervice request pulse from 

the cl.eiU, jpd inc 1 ost ^-eLi nibhrE; -Jie Mi'DLD"ilpn 

andML»DI_Stb dnver outpu ^ri . u, i nj in, I ,md 

MDDI_Stb to a logic-zero level lor as iong as ii should talce lor the diivers to enable 
their n otc 'nv uulput*. Yh^ host ivnicullv ^ a. I , ^Ttoi rjd 200 nanojeconds after these 
ontpuL reach dciircJ Ingjj ic\c[<! i-clor.. dn\uiL' pui^jii IviUOl Stb. This allows the 
clieni tiint to prepure i" rece3'"e 
[00256] Wilh die ho^i .'Mixefs eita'ileci and NTioT^D t<jO H-ip-i OMren to a logic-one 

level thf ho&l tegjfLS onlpuanig pulses on MDP1_S h fo. a duM'ju i of 150 MDDI_Stb 
cycleh J!- S4e[t ai point F Uh&n the client iccn^^iiiZi*; tUc - i^t pu --.s on MDM_Stb it 
disables the offset m its MDDL.Stb leceiver. The client continues to drive 
MDDLDataO to a logic-one level for 70 MDDI_Stb cycles, and disables its 
MDDI_DataO driver at point G. 
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[0D2S7] As seen at points G and H, the host drives MDDUDataO to a logic-zero level for 
50 cycles, and the client begins to look for the Sub-&ame Header Packet after 
MDDLDataO is at a logic-zero level for 40 MDDI_Stb cycles. The host begins to 
transmit data on the forward link by sending a Sab-frame Header Packet, as shown at 
point I, 

[00258] An example of the processing steps for a typical Host4nitiated Wake-up with 

contention from the cli«it, that is the client also wants to wake up the link, is illustrated 
in FIG. 68C. 1'he events are agaui labeled for coiiyfcmence in iHustmtion using the 
letters A, B, C, D, E, F, G, H, and I. As before, the process commences at point A when 

the host sends a Link Shutdown Packet to inform the- client that the link will transition 
to the low power state, proceeds to point B where MDDI„Stb is toggled for about 64 
cycles (or as desired for system design) to allow processing by the client to he 
completed, and then to point C, where the host enters the low-power hibernation state, 
by disabling the R-IDDLDataO and MDDI_Stb drivere and placing a hos.t controller in a 
low power hibernation state. After some period of time, the host commences the link 
■restart sequence at point D, by enabling the MDDI_DataO and MDDL Stb driver output, 
and begins to toggle MDDLStb for a duration of 150 MDDI_Stb cycles, as seen at 
■point E. 

[00259] At up to 70 MI'IIL'^ ' i.-. .fv, r,,;, .i fc .c pon- P, ih^ ; 'oni 1-f.s not yet 

reco^ized thai the ho ' is v'. Mi'!;i i) t o ,5 i ioF.r-o..e v->'cl ■^o thi chmi ,lso 
anvss NlDDI„DataO to a io: c in: occur hcic because the chsnt hab a 

aesirc to rcqi'Ciii bcrM^c bul ti e t\>j i\>e iiott ii is trying to communicate 

wini Ivs ili'^ I .-.■■Ttb. > - , - 'ii [It 1 n tl e i-heni feas.es 'O dnve 

VfTj 1 J) ') . ' ! 1c It, 'icfibhng Its Output. 

.,s.l,L.|. iinu.l . % - ! K J. .i c0..ddit<. na:t>/c]c-. 

[00260] The host drives ^i'lDDLDataO to a logic zero level for 50 cycles, as shown at 

point H, ai>d the cUent begins to look for the ■Sub-frame Header Packet after 
.MDDLDataO is at a logic-zero level for 40 lVlDDI_Stb cycles. The host begins to 
transmit data on tlie forward link by sending a Sub-frame Header Packet, as shown at 
point I. 



VI. Interface Electrical Specifications 
[00261] In the example embodiments. Data in a Non-Retufn~to-Zero (NRZ) format is 

encoded using a date-strobe signal or DATA-STB format, which allows clock 



wo 2004/110021 



PCT/US2004/017579 



infomatjon to be embedded in the data and strobe signals. The clock can be recovered 
without cpmpfex phase lock loop circuitry. Data is carried over a bi-directional 
differentia] link, generally impiemented using a wire-line cable, although other 
conductors, printed wires, or ttansfer-eleinents can .be tised, stated earlier. The strobe 
signal (STB) is carried over a uni-directional link which is driven only by the host. His 
strobe signal toggles value (0 or 1) whenever there is a back-to-back state, 0 or 1, that 
remains the same on the Data line or signal. 

[00262] /in oxaniolc oi bow a data sequence such as bits "1110001011" can be 
frtiti-. 11 M J DATA MB cjKodmg n shown ni gi^dnhical foim m FIG 40 In 

FIG 40 a ^)^M A si^ eiI 401. -.houn on the top i ii- ^.i ^i"! ti i L.hart and a 
■^fb signal U'd t u "I r i ^ - onJ hnc ccth iv il a^^cd a'' 2ppji'"p"a*-c (.common 
atirting pert* V ^ ^here i <.*^ n^e o u 'c oxuniTio or the DATA 

hne ^'Ti? "p s niLi Uk i b -j- lO-i (n^tnl) nut i1 ni'^ i pc^NHUi': p, rin-v irie 
hiv 1 Si Hfo[>i'-D\T^-ijii u riHc-s iilnhp nsf 0 sUti lo iU ^jii^i-rn.u us 
st*rti)* \ .11. H.M ti if i> «ul C- 1. IV T "1 d c "ot 

change then the SI L "-jgiial t-c:?'L oh "p-., I J te or 1 m the pre-uit t, ampJt, as 
13 tr; 1.3=0 n 1 < (t 'h t c 1 ^ > i ^ i o h r \ i n I!i i 

Die and -n.', oi c rt,nb ion tju b t cjcie betwee i 1^1 ^ tn_ STB Th it f"c STE 
^ii^n^l TMr^ts 1 -1 1 II d^h " > f •^AT'i ^u'i". i ' 'n.„lil^s'hs 

l-v'o s.-lu i.ii DM^ cl T 0 V'l-r -'I DM^ j^rUt-v at 

I hk. n> ij-iiol £:a;'c^ vi 1 n th^ p-^-ser'" c lan" Me ard -.o 

tOi.th the D V r V "isnai ' u.,x 

I002b't Jjoi e_ei\ 114 Mi-"-- OR (kOR) uperd'ion ««• p- <■ in <>m 

(Ir- - ltd "^TB MO I il k.ck signal 4006, which .<• m m i I c 

b->ti I )l lU ! nnn^ Jnrt 1 h k. o r.ijsoi vvjtS di d% 1 e 1 it I ui 
sign il \Ti V, V implc ot ur ittv u viul f-i ^ t ^ L ■* ' \ aid It ..inir^ or 
«!ign...U hv-nx irpat data at the ho^t, and Lhc 1 ^^o vii g 0 s up u i\~t t dnt" i "i tre 
DA J~A and STB signals at the chenL is shown in FIG. 41, 

[002d4J I TTTG ^il > trdiisniissjon pontjon 4100 is u-.c" to ^jfii'^utt j ti'-ii 1 tie 

original DATA and STB signals over an intermediary signal path 4102, while a 
reception portion 4120 is used to receive the signals and recover the data. As shown in 
FIG 41, in order to transfer data from a host to a client, the DATA signal is input to two 
D-type fHp-flop circuit elomeats 4104 and 4106 along with a clock signal for triggering 
the circuits. The two flip-flop circuit outputs (Q) are then split into a differential pair of 
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Signals MDDUDataCN-, MDDI^DataO- and MDDI__Stb+, MDDl_Stb-, lespectively, 
using two differential line drivers 4108 and 4110 (voltage mode). A three-input 
exclusive-NOR (XNOR) gate, circuit, or logic element 4112 is connected to receive the 
DATA and outputs of both flip-flops, and generates an output that providies the data 
input for the second flip-flop, which in turn generates the MDI>I_Stb+, MDDLStb- 
signals. For convenience, the XMOR gate has the inversion bubble placed to indicate 
that it is effectively inverting the Q output of the flip-flop that generates the Strobe,. 

[002653 1:1 ret eplion portion 4120 of FIG 41, the MDDI_DataO+, MDDI_DataO- and 

MDDI_Stb+, MDDI_Stb- signals are received by-each of two differential line receivers 
4122 and 4124, which generate single outputs from the differential signals. The outputs 
of the amplifiers are then input to each of tlie inputs of a two-input exclusive-OR (XOR) 
gate, circuit, or logic clement 4126 which produces the clock signal. Tlie clock signal is 
used to trigger each of two D-type flip-flop circuits 4128 and 4130 which receive a 
delayed version of the DATA signal, tlirough delay element 4132, one of which (412S) 
generates data il i I ' 1 t I il ie"^ 1 i ui 

independent output ii ni l t ^ )I i l 1 Sin c the clrcl int imation is 

distributed between the DATA ana 8TB lines, neither signal transitiGns oetween states 
faster than ha o tl < i «1 l J g i c^^l «ivc J" 

processing o:^ t e „ a i i ii it c ively tolerates rwice f-e 

amount of sLev bp ween h o~i ed to the situation when a 

clock signal is sen* d re^-tlv o\c ^ si ^ ^ ca ^rt 1 

[002661 The Iaj^i Da a pairs MUDl Sib)- and Mi> i ^ 

differential mode to maximize immunity from the neghli\t. Jlcvts m >i. uf-n Each 
portion of the differential signal path is source idiiuiHt, < mi ,k ,( ■ of the 
characteristic impedance of the cable or conductor brn.i ^^-:^\ k' !-.i!f,'i.\ 'iicii.ils. 
MDDI Data pairs are soiree T-rrninated at both the host and client ends. Since only one 
of these two drivers is active at a given time, a termination continuously exists at the 
source for the transfer link. The MDDL$tb+ and MDDLStb- signals are only driven 
by the host. 

[00267J An exemplary configuration of elements useful for achieving the drivers, 

receivers, and terminations for tL'ansfemng signals as part of the inventive felDD 
interface are shown in Hd, 42, while coiTesponding DC electrical specifications of 
MDDI„Data and MDDI_Stb are shown in Table VII. Tiiis exemplarj' interface uses 



wo 2004/110021 PCT/US20&4/017579 
58 



low voltage sensing, here 200 mV, with less than 1 volt power switigs and low power 
drain. 



[00268] TABLE VH 



Parameter 


Description 


Min. 


■tvp. 


Max. 






Series Termination 


41.3 


4.?,2 


43.0 


Ohms 


: Rwhsrnate 


Hibernate State bias termination 


8 


10 


12 


K-Ohms 




Hibernate State open-icircuit 
voltage 


0.5 




2.8 


V 


Vootpm-Ranije 


Allowable driver output voltage 
raiiae with respect to GKD 


0 




2.8 


V 


VoD^ 


Driver differential output high 

voltage 


0.5 






V 


VdD- 


Driver differential output low 
■ voltage 






-0.5 


V 


ViT,. 


Receiver differentia] input high 
threshold voltage 






10 


mV 


VlT- 


Receiver differential input low 
threshold voltage 


-10 






mY 


^ feput-Range 


Allowable receiver input voltage 
range with respect to GND 


0 




3.0 


V 




Input leakage current (excluding 
hibernate bias) 


-25' ; 




25 


ma 


The electrical parameters and characteristics 


of fh,<' 


rUffert; 




drivers and 



line receivers ai-e described in Table VIII. Functionally, the driver transfers the logic 



level on the input directly to a positive output, and the inverse of the input to a negative 
output. The- delay from ii)put to outputs is well-matched to the differential line which is 
driven dilTerentiaily.. hi most iniplomentations, the voltage swing m tl?e outputs is less 
than the swing on the inpiii: to minimize power consumption and electromagnetic 
emissions. Table VHI presents .a n;i nirnuni voltage swing to be around 0.5V. However, 
other values can be used, as would be known by those skilled in the art, and the 
inventors contemplate a smaller value in some embodiments, dependmg on de^gn 
constraints, 

[00270] The differential line receivers have- the same characteristic as a. high-speed 

voltage comparator. In FIG. 41, the input without the bubble is the positive input and 
the input with the bubble is the negative input. The output is a logic one if: (Vinput+) ~ 
(Yinput-) is greater than zero. Another way to describe this is a differential amplifier 
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with very large (vittuaJly infinite) gain with the output clipped at logic 0 and 1 voltage 

levels. 

[00271] The delay skew between different pairs should be inininuzed to operate the 
differential transmission system at the highest potential speed. 

[00272] In FIG. 42, a host contfdlief 4202 and a client or display controller 4204 are 
shown transferritig packets over the communication link 4206. The host controller 
employs a series of three drivers 4210, 4212, and 4214 to receive the host DATA and 
STB signals to be transferred, as weR as to receive the client Data signals to be 
transfei-red Tu t'l '<ri spisT^iba (orptissi^t ol Liic host D \TA eirp'ojs an enable 
^i^iul ni^^Li u sDi H LT(\a on )t the romiPuii]^.riicn ' nk ^ T-r^lK orilv 'i i r i t^T 
hem h^. h i^t -i \^<. i t r i .bs red Sirce t! c is IB .3ral i'' tormcO a par ^ns 
ti.criSlcr da a aJ-^itiona' enaole ^'s^j " ei p ^^^el f"^ iba an\L'- v!ii2) Pie 

0 itru* L 1 b >i c D^T-\ ird stb ]< v-j*- Me i MT=>i.ti o lo tcmi nan -,p \ ^pedanfe" 
(1 ies!<-U>(s-i''li)i 4"'it»n 42 fx nd 1/ lod ie'->ei,1ue\ 

[0Q273] Jc liiii 0 K I'^tn ■^'"i did 4il6b 1 c K i tio^hl. s -t tic nrut 

01 t t I It 11 Ki It for the STB signed orc( %i nh i .dci^ona- 
tsmr 1 o K 1l I ^ _ ^ "1" "1 cc n ens« ' ib si jj 2.6'" ana 
42J<)d lb pcLti cl\ on the npi if " l lui t >i'xes-ing receiver 4222 A sixth 
d" -^-r i ^1 II ll * ! '^t'^ li^ trai -te-red 
Ini 11 I- 1 ( ! I - o , 4 "'c nd 

■'IfKl .[ t It u [Hi I T - -ins 

[00274! i o cdi .0 ' i-b re piac^L is iia 

re^ J d iir l''^- \^ ^ '■_ -i ] u! ^h'^ hi'^emdUop 

copuo' t'i<L'i-S(.dci^e\x leic Th<"\oli<){»f s ■ v li uansfer lines to ttie 

hi^K 1 >v ]. \< '.T-iev'H us'vdi n-^is-dluL c. t \ !0 < dui 
[002751 ih'- pbT\e d >/wi <<n\' iripeJ nt-i^ o ta be i0ji.cl <i> It-uc-'c cii p r-^ t 

pir! it vi It m^dtjlv 01 an aiphv,^ il ir tj^ t„d c ii.Jit « ''Sl^-i ' i- ^.r e 

as a more cost effective encoder or decoder solution. 
[00276] It can be easily seen that power is transferred to the client device, or display, 

from the host device using the signals labeled MDDI_Pwr and MDDI„Gnd over a pair 
of conductors. The MDDLGnd portion of the signal acts as the reference ground and 
the power supply return path or signal for the display da\ice. The MDDLPwr signal 
acts as the display device power supply which is driven by the host device In an 
exemplary configuration, for low power applications, the display device is aUowai to 
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draw up to 500 inA. The MDDI Pwr signal ean be provided from portable power 
sources, sach as but not limited te, a lithium-ion tj.-pe battery or battery pack resicjing at 
tbe host device, and may ran^ frqtq 3,2 to 4.3 volts with respect to MDDI_Gad. 



VII, Tiiiitng Oiial^actgiislics 



A. OTcrview 

[002"'"' 1. „ . ■ 1 jliunt to secure service from -li'. Loi 

And by the host to provioc -e. , . c, ii. illustrated in FIG, 43. In FIG. 43, the first 
pail .'I signah ''itfuz iihi^b,!!- i. ■^Imx.-. , ] .nk Shurdown Pricifet bcing ti-iir;'"] fio. i 
the host and the ds.Ta hnc is (hrTi dr, .i-n r. lope 7cio state u^tng ths hiEh-mnpcdar.cj 
bias circuit. No da:a is cema transmitted dy tlie cber.t diEpiQ), er host, vaiieh has iis 
driver dibiibl'^c A scnot of trrobc pulses for the MDDl_S'b ■sigti.il nn-» be ^eci at 
ihe lin ii)n. "-mrt; ^ITiDT ^tn is 'ictive during the linl 'sljutdown PuKet Omt- ais 
. pat-kct ciid' aiiJ the hv., h'\i>! i-hanges to zero as the 1. xsl -uincs Ki. t>,,'^ ji.v.j. r.d 
logic to zero, the Mni>! S :is,;,n, Ime changes to a zcru ;1 o; w cl: I 'i, > -i:f( its 
the termmatioii ol the last signal transfer or service from the host, aad, could have 
p;^' < u 1^ ''c'l'L' '> 'i-\H the- piiei ceb'-:v!on oi ser. ce, 
and iIh m 'i- t ilr •■ p '-h «^ei''He'M' ni^,,, ; rncnl If desired, such as signal 

I ' ' ■ ■ ■ . 1. ! >tf.!r vviliiout a 'known' 

pnot comnran icaoon having been undertaken by this host cicvice. 

[002 "L, A- -rs'v r T IJ . '\ " .ignal output ftx>m tf> : ■ it is 'h .rt a: a logic 

level ot zero. In other words, the client output is at a htgti impedance, and the driver is 
•iiiiibk'l WiKii invK'i !s l>eni.>. leq ic-vn. ohfn, -liable- i1s dnver s^iid ii i 
S'-mu u'tiut-sf to tho hr>s1. is fi pcnod ofihw. dc>.i^..«.(cd p->civi' i .'iiriM- ^^Acc'i 

'he 1 nc u .""nvcn to a io^ic one level, A ccrtiun amrunt ot time ihcr\ p i'-si i. li- m.ii hs 
needed octoie tnc host detect.^; the request, termed thost-dctcei. a.Ltr ^/nict hcjt 
responds n ith a linl^ stutup sequence by driving the signal to a logic 'j-n^ lev A Ai iiii 
po'V' ''f ; h'='n< cc-'isseris 'he reqne?!, 'mrl disables the service request driver so diat the 
lupol ] ir I'o.'i tbr chcTU 50e.-i lo a zeio logic level again. During this time, the 
MDDLStb signal is at a logic zero level. 

[00279] The host dtives the host data output at the T level for a period termed trestart- 

high, after which the host drives the logic- level to zero and activates MDDLStb for a 
period temed trestart-low, after which the first forward traffic tegins with a Sub-Frame 
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Header Packet, mid liie forward traffic packets are then transferred. The MDDI„Sflj 
signal is active during the trestart-low period and the subsequent Sulj-Frame Header 
Packet. 

[00280] Table VHI shows representative times for the length of the various peiiods 
discusaed above, and the relationship to exempiaiy minimtim and maximiuii data rates, 
where: 



ijiak_Data_Rate 
100281] Table Vm 



Parameter 


Description 


Mn. 


Typ. 


Max. 


Units 




Duration of display sen/ice 
request pulse 


60 


70 


80 


jisec 


trestort-high 


Duration of host link: restart 
high pulse 


140 


150 


160 


jJlsec 


tiestart-lo-w 


Duration of host link restart 

low pulse 


40 


50 


60 


fisec 




Time for display to detect 
link restart sequence 


i 




50 


[JISSC 


thost-detsct 


Time for host to detect 
service request pulse 


1 




50 


|isec 


1/tbft-nmi-peif 


Link data rate for a minimum 
performance device 


0.001 




1 


Mbps 


l/tbdt-naix-peTf 


Maximum link data rate 
range for a device 


0.001 




450 


Mbps 




Reverse Link data iaf e 


0-0005 




50 


Mbps 


tbi! 


Period of one forward link 
data bit 


2.2 




10*' 


nsec 



[00282] Those sldUed in the art will readily understand that die functions of the 

individual elements illustmed in FiOS. 41 and 42, are well, known, and the function of 
the elements in FIG. 42 is confirmed by the timing diagram iti FIG. 43. Details about 
the series terminations and Mbemation resistors that are shmvn in PIG. 42 were omitted 
from PIG; 41 because that information is unnec^sary for a description of how to 
perform the Data-Strobe encoding aaid recover ttie clock from it. 
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B. Datei-Strobe Timitig Forward Link 

i:00283] The switching characteristics for the transfer of data on the forward link from 
the host driver output is sho-wn in Table IX. Table IX presents a tabular form of the 
minimum and maximian desired, versus typical times far certain signal transitions to 
occur. For esan^le, the typical length of tiiiie for a transition to occur from the start to 
the end of a data value (output of a '0' or 1% a DataO to DataO transition, termed ttdd- 
(host-output), is ttbit while the MoiiiilQum time is about ttbit-0.5 nsec, and the maximum 
is about tthit+0.5 usee. The relative spacing between transitions on the DataO, other 
data lines (DataX), and the sti-obe lines (Stb), is illustrated in FIG. 44 where the DataO 
to Strobe, Strobe to Strobe, Strobe to DataO, DataO to non~DataO, non-DataO to non- 
DataO, non-DataO to Strobe, and Strobe to non-DataO transitions are shown, which are 
referred to as ttds-(host-output), ttss-(hGst-output), ttsd-(host-Gutput), ttddx~(h;OSt- 
output), ttxlxdx-(host.output), ttdxs-(host-output), and ttsdx-(host-output), respectively. 

[00284] Table IX 



Paramete^r 


Description 


Min. 


Typ. 


Mas. 


ijnits 


ttdd-diost-mitmit) 


DataO to DataO transition 


tftit-0.5 






nsec 


'*Isihast-o'#j!t), 


DataO to Strobe transition 


tt„i -0.=^ 


ttbit 




ll'-CC 


Wchost-oittpm) 


Strobe to Strobe 
transition 


Tm - 


tlbil 


tcaii + 0.5 






Strobe to DataO transition 


Jly.l_-_OJ__ 




tftit+O.S 


nsec 


tsMx-OwBt-outpirtj 


DataO to non-DataO 

transition 




tsbil 






tld'.dx-(host-Dutputi 


fion-DataO to non-DataO 

transition 


ttbtt-0.5 






nsec 


ttdxs-^liost-output) 


non-DataO to Strobe 
transition 










ttS£fe.-(h05t-0Utput) 


Strobe to non-DataO 
transition 








nsec 



[00285] The typical MDDI tiirrii.g .'equ rern.^r.t^ P v the client ! tteivui iiipai for Ihe ==amc 

signals transferring data on the fum a li I , -l-ovn m Table X Since the samu 
signals are being discussed but time delayed, no new figure is needed to illustrate the 
signal characteristics or meaning of die respective labels, as would be understood by 
those sldlled in the art. 



wo 2004/110021 



PCT/US2004/017579 



[00286] Table X 



Parameter 


Beseriptioni 


Min. 








ttdd-(elispky-inpiit) 


DataO to DataO transition 


ttbii-1.0 


ttbit 


ttbit + 1.0 


nsec 


ttds-fdisBlaV-intmt) 


DataO to Strobe transition 






ttbit + 1.5 


nsec 


ttss-fdisplav-iiiput) 


Strobe to Stiobe transition 




ttbit 


t*ir+1.0 


nsec 


tW-(display-inpM) 


Strobe to DataO transition 


Wl-1.5 


ttbit 


ttbit -i- 1.5 


nsec 


ttddx-fhost-outpiit) 


DataO to non-DataO 
transition 




ttbit 






ttdicix-Chost-output) 


non-DataO to non-Datjrf) 

tranisition 








nsec 




non-DataO to Strobe 
transition 




ttbit 




nsec 


ttsds-^hast-output) 


Strobe to non.-DataO 

transition 




^tbit 




nsec 



i<i t. ' ' tlij!S. 45 and ib illu-.tiare rfie pn^ionce of a dt^'.ny in response that can occur 

vv'neu v'ne h. «t chtabki e"ch!e' tiie hobt arr.ci, :v-,peclvvely. In the case of a host 
forv kul.n;. < M'lM jvJ..-f-, <!!• t. the Revei^e Link Encapsulation Packet or the 

RoL.M<; Id . li'li) Mta- T. acket, the host disdbbs the line driver after the 

dci-Acd r-.t i-t^ Un \ 1 . ,„. f, ab the Parameter CRC. Strobe Alignment, and All 
''I' '1 , b i!;-i-irji;a .;. ; \: , 'r ,.s havnig |-)een transferred. However, as shown in 
"lO 45. inc u'.iic t Vi -Tr : not necessarily switch from '0' to a desired higher 
vuhie M^st-'Piaico^i^jij, ■■ ti"> 'his is potentially achie-vtible with certain control or 
Ciu-iiii ^-jt-ments present, but uiu s a period of tinne terrned the host Driver Disable Delay 
period to respond. While it could occur virtually instantly such that this time period is 0 
nanoseconds (nsec) in length, it could more readily extend over some longer period 
with 10 nsec. being a desired maximum period length, which occurs during the Guard 
Time 1 or Tui-n Around 1 packet periods. 

[00288] Looking in FIG. 46, one sees the signal level change undergone when the host 

Driver is enabled for transferring a packet such, as the Reverse link Encapsulation 
Packet or the Round Trip Delay Measurement Paeket. Here, after the Guard Time 2 or 
Turn Around 2 packet periods, the host driver is enabled and begins to drive a level, 
here '0', which value is approached or reached over a period of time termed the Host 
Driver Enable Delay period, which occurs during the Driver Re-enable period, prior to 
the first p^ket being sent. 
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[00289] A similar process oceiirs for the dri veis and signal transfers for the client device, 

here a display. The general guidelines for the length of these periods, and their 
respective relationships are shown in Table XI, below. 

[00290] Table XI 



Description 


Min. 


jVtax. 


Units 


HostDii-te !"-■!' .-''..>, 


0 


10 


nsec 


Host Dri' _ . . ^ ZT; 


0 


2.0 


nsec 


Display Dfi *fei I Jisnble Delay 


0 


10 


nsec 


Display Driver Enable Delay 


0 


2.0 


nsec 



C. Data-Strobe Timing Reverse Link 
[00291] The switching characteristics and timing relationships for the data and strobe 

signals used to transfer data on the reverse link from the client driver output are shown 
in FIGS. 47, and 48. The typical times for certain signal transitions are discussed 
below. FIG. 47 illustrates the relationship at the host receiver input between the timing 
of the data Ixiing transferred end the leading and trailing edges of the strobe pulses. 
That is, what is ref stred to as the set-up time for the rising or leading edge of die strobe 
signals, tsu-sr.and the set-up time for the trailing or falling edge of the strobe signals, 
tsu-sf. A typical lenglh of time for th^e set-up periods is on the order of a minimum of 
8 nanoseconds. 

[00292] FIG. 48 illustrates the switching characteristics and corresponding client output 
delay developed by the reverse data timing. In FlG. 48, one can see the relationship 
betwe^i the timing of the data being transferred and the leading and traiiing edges of 
the strobe pulses accounting for induced delay. That is, what is referred to as the 
propagation delay between the rising or leading edge of the strobe signals and the data 
(valid), tpd-sr, and the propagation delay between the data and the trailing or falling 
edge of the strobe signals, tpd-sf, A typical maximum length of time for these 
propagation delay periods is on the order of S nanoseconds. 
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Yin. Mpleraentation of Link Control (Link Controller Operation) 

A. State Mkchinie Packet Procf^sor 

[00293] Packets l^ing transfejted over a MDDI link are cEspateKed very rapidly, 

typically at a rate on the order of 300 Mbps or more, such as 400 Mbps, jiltbough lower 
rates are certainly accommodated, as desired. This type of bus or transfer liiifc speed is 
too ^ 1 fir currently commercially available (econoimoAl e la pjijj 
iTiicrGprocessors or the hke to control. Therefore, a practical implemeiiitatioii to 
accomplish ihis ivpc ot signal tr« i o uiili/p a piognramable stite niarh-nc to 
pars? '•h^ npirpi-l't, ■^tiu.^m op < r 1 f i t t i j ii tciifdd s uiin-U 1 imIil 
appropnac djuo b J iu^) ) *cm tor whiuh tl ^.rc irtc idt,d S tb \ utsarewdl 
knowTi din n<iL ^ itcuiK- ^^1- es M\ dtdic * c J a i ir t<»d Ti..rrbei ot ops, tl oi f Jict Oi ^ 
or Slat s 10 \d i\L. 5 v ■'b p^, -"Si ii -.1 Cf J vpt'^^V o" 

[00294] licn i.l i i t n <w i i< . mp 1 r> i « i Ii i < I 

pack » \ idi h n \i lei ^i^. l t^-c^as scoi ro s aXu^ or 

othci ) i^ti- piJe ' I nate machine hoald Dai*- the-i tTxTCj^h a 

data 1. f o 1 1 p J t. 11 ' T! r 1 pi3T>c«c p'"oce^sor so 'he 

packi t r Ik utc( 11 o I j-rosi wh 1 t"c djc n d-ic ''"'^aal 

pack' t ^iL. tTan uiiduoii for actiun it jij ari., 

niicroi lo - u Hers, processors o djc Leasing 

elem.'-ii ne nu u' i t„ c_ i „ ^ ^ i te processing caoub iit 3 li r the 

states or state maehine discussed below might also be implemented using software 
control of such devices, typically as programs stored on a storage element or media. 
[00295] The general purpose processor function can be realized in some embodiments by 

taking advantage of the processing power, or excess cycles available for, 
microprocessors (CPUk) in computer applications, or controllers, processors, digital 
signal processors (DSPs), specialized circuits, or ASICs found in wireless devices, in 
much the same manner as some modems or graphics processors utilize the processing 
power of CPUs found in computers to perform some ftmctions and reduce hardware 
complexity and costs. However, tliis cycle sharing or usage can negatively impact the 
processing speed, timing, or overall operation of such elements, so in many 
applications, dedicated circuits or elements are preferred for this general processing. 
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[00296] In order for image data to be viewed on a display (micro-display), or to reliably 
receive all packets sent by the host device, the display signal processing is synchronized 
with' the forward link channel fimiinig. That is, signals arriving at the display and the 
display circuits need to be substantially time Synchronized for proper signal processing 
to occur. A high levd diagram of states achieved by signal processing steps or a 
method by which such a synchronization can be implemented is Jicsc iied in the 
illustration of FKJ. 49. In HG. 49, the possible- forward link Rvnchromzation "states" 
for a state machine 4900 are shown being categorized as one AS.Y¥:c FR/vMES 
STATE 4904, two ACQUIRING STOC STATES 4902 and 4906, and three M-S YNC 
STATES 490S, 4910, and 4912. 
[00297j As shown by starting step or state 4902, the display or client, such as a 

presentation device, starts in a pre-selectcd "no sync" state, and searches for a unique 
\-\Oid ij ihc fir> sjt jjame hrider piukc i th V js de'e Lt I' le be "c^eJ ^hat chia no 
u«. icpicscnt-, the inn sit in < -xiimi ii nion "-ulipp fill vt setting in 
Hht'iaT pt 1 !"tert£ic= 13 ca^d Uhei i i \ lo i s. \<] i uk. d lu^ I he search,, 
(hb diiplj\ ^a\e- the b f-d"ie length field I it ^ i ^ i u li f.C bits for 

p 0 cs<:u g un t'>i'- firb* "ri^ie, or until syrc-i- j ti ii , h ji . li JUi, sub-frame 
kng*h 7cio 1,1 ti vvnc ^late piocessmg pre ^ i d i<l, to i ,'a'o 4^04 labeled 

he.^a^*ie a-Nw i l i \ i 1 m k k n at l not yet been 

<ci.c\Ld "I 1 iM ^ ciu 1 il-t-d ?ond 3, or 

<H t 1 ^ 1 PlL 0 I iciigtli IS greater than zer.>, then the 

* ii lo. f^-Mi i pic where the interface state set as "found 

» I liHiii " . f-ig 1 ijbcled as cncountenng cond 5, or 

1^ iLor 1 I ( - pviL nire '•c- s jl frame header packet and 

20 jd LK.C dee. mention it.r u iiame leogth greater than zero, processing proceeds to 
UK fuand one sync frame" state. This is labeled as meeting cond 6. or conditioni 6, iii 
FIG, 49. 

[002So! 1( I ■« !i sit iiMon nt which the '■ystem ib in d. i,«-<ite ofisi t^irn nc , when the 

r q 1. . tli-t. L-Kd arfd .3 good CRC jesult ts d^-lern w"-' I u ti t t,n!? Ir me header 

^^^^ t cjn. ihu J trains tengflus gieatoi than /eio, chei Ihe iw^r^ e <,( t- is changed 
oil. n Miv ta^-c -iW' Ihio stop in thepiocensijing IS ( ihi' t 3 i'- J a v-ing encountered 
cood 1, or condition 1, in FIG. 49. On the other hand, if either the unique word or the 
CRC in the sub-fmme Header Packet ate not coirect, then die sync state processing 
proceeds or returns to the interface state 4902 of "NO SYNC FRAME" state. This 
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portion of the processing is labeled as eneouotering: cond 2, or coflditioft 2, m the state 
diagram of FIG. 49. 



Acquisition Time for Sync 



ifigured to accoftsmodate a certain number of "sync 
1 1 u iLT 1 1 t Ji^ I HI 1! V tu tlie NO SYNC 
h J-^lrhn ^ iLi J I 1 IN n'NC STATE 



U I 



changes 
Jesuits in 
t sn <■ o u n > rri. -jtsitc, 

^le 'tdt*- 1 ^^.^i e to Jie IN 
110 It-e , i?e nil li'ii" t-^litniT 
)uld the mtrtl Ke encounter a 



[00299] The int&rfaee can be 
errors" poor to deci^ i ^ - 
FRAME natc Ir -1^ > 

andnoenois u Lin_ i i tut ii m 
the: "IN S\N( '^t«L Hu \e ei on ( 
the bi^e t 3 OiR -.yi ir T >tU( 
detectirg jint-^of c^rti I >! 1 h - 
othei vi^^e i+ e"i.o^n'"ei:> aroti^r con i _ 
state 4^2 4f ir if I LH ' * n > 
SYNC le iliienM',!. ^rom 
to th II \ 1 It r J 11 
■ "link shutdown packet", 
retoi" tc ii li i 
referred to as meeting cor 

100300] line o .] 1 

uniqu vo d [i.h i i 
situauon, it is highl > ' 
becaose the CRC on tlic 
order for the MDD mteriace p^ocesslIl^ to proceed to tlie "UN S I NU" state. 

[00301] The sub-fraine length in the sub-frame Header Packet may be set to zero to 

indicate that the host wil] traiiSKiii only one sub-frame before the link is shut down, and 
the MDD interface is placed in or coBfigured into an idle hibernation state. In this case, 
the display must immediately receive packets over the forward link after detecting the 
sub-frame Header Packet because only a single sub-frame is sent before the link 
transitions to the idle state. In normal or typical operations, the sub-frame length is non- 
zero and the display only processes foward link packets while the interface is in tlK>se 
states.collectively shown as "IN-S YNC" states in PIG. 49. 

[(X)302] The time required for a display to synchronize to the forwai'd link signal is 

variable depending on the sub-frame size and the forward link data rate. The likelihood 
of detecting a "false copy" of the unique word as part of the random, or more random. 



will cause the link to ttamiiiate da 
•^s there is noth n_ iu i iic i 
_ )'•> ' 1 at, cijv., a lot '"K) 

s li- I heie to be a lepeating la 
. I- In^d location ^Mthni the sub 



vvlie 



p t L the 
1 1- Tt li 1 
I. sab iiame 
in 
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data in the fqrwaird link is gi^ater when the sub-frame sizt is larger. At the same time, 
the abUity to recover from a false detection is lower, md the time taken to do so is 
longer, when a forwmxl liirik data rate is slower. 

C. Initialization 

[003033 As stated earlier, at the time of "start-up", the host com i smrss tnc forward 1 1 nfc to 
operate at or below a minimum required, or desired, data rate of i A'lbps, and craitifjures 
the sub-frame lengUi and media-frame rate uppiopriHih. i<i j. jh.en A-:-i--:viiiO':. J't.-a 
is, both the forward and reverse links begin operation using the Tjpe-I interface. These 
partiroeters ai:e generally onl; _ ■ \- -.ncd tcmpuninly ^vla.k" lli/ : n^t ik-kirit>iii;-i 
the capability or destrea err -■ .• -. she client ihirsl^y (or oth,T tjpir ci" cijcnt 
device). The host sends or . •^zvm Header Fackci over the lorvvard Imxi 

followed by a ReverS'^ Iuik [■- • i ?.,;kcfl which has bit 0 of ihc Request Flags 
set to a value of one ( j "> jri orikr jj icq-jtf-l Lh?i (be- d!.sn];iy or 'jlienf re-^ponds. '■yi'h a 
Display Capability Piu;ki!-. (> iu; 'die display acquires synchiomzaUon on (or %'ith) the 
forward link, it sends a iJispfav Capability Packet and a Display Request and Status 
Packet over the reverse hnic or ciiannel. 

[00304] The host exarnui-ji- &c v.jri;- ol the Display CapabUity Packet in order to 
determine: how to rcf')Mfij;>i'i' vi' '"■ '. nplinyl or a desired level of performance. 
The host examines Piii" Vi.v,,.,-, ,, ,i M.iiimum Protocol Version fields to 
confirm that the host and display use versions ol ihe protocol that are, compatible with 
each other. The protoccl versions pencraily , , ;\> 

display capability Packet so that compatibihty caii be detenimied uvcn wiicu oJicr 
elements of the protocol might not be compatible or completely undsKtood as being 
compatible, 

D. CRC Processing 

{00305] For all packet types, the packet processor state machine ensures that the CRC 
checker is controlled appropriately or properly. It also increments a CRC error counteir 
when a CRC comparison results in one or more errors being detected^ and it resets the 
CRC counter at the beginning of each sub-frame being processed. 
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E. Alterniatif e Loss Of Syncliroiiization Check 
[00306], While the above series, of steps, or states wts'k to produce higher data rates or 
throughput speed, Applis aiiis h m tlit.* ovoed that an alternative arrangemeifiit or change 
m flis c urjd/ioiiij flk cll-'i > i il > J dl thcit I's. p Ic^s » i ^\7ul n ]/ u i ' ih 11 1 



states bhaneed \_di o I\ r in i! i e r «1 i j 1 1 i I n 1 1 ior 
sub ttdme s>nt,bioni7^ti n Th - "^leps nd i lait m it a presented islatii^e 1o FfO 
(Ti ill I il ii>ti ili ft saii - if sn s ai li (Old !(n<- liSt il II tMrilsniwy Ihe 
o Ci I on-. ^.1 tl r maSos' r '■tate irarhjnc Or' ^ ' V (^t IRlNCi iANL S'AILS 
ard'lis SVNC bl \1 nctti^n-. arc shown tor c'a, f 1 ddditioi, c n^^ ^ic rcsultirg 
td^^e re bibb i^ti^M-', 'he ^smi is the s j^-^ jna^h iti^^lf, ^^i*-" i ^ the ■^ciire 

ore vU on.) vciiy Mj itivhjl "-oif « u j • 1 i LnU i. wuj i ii t \ U vis 

,] 2, i 5 aad »i 11 -i . 1 1 to \i Ki ^ 1 d h ^n.^ 

d "s.eiXes Si ice t]ii>. "^v^ iR \Ajd i.« i t t hI lu k d o re 
s^ate j4 ) a ic co.idiucn (b) arc no longci usi i ' u 

[OOJ J Im nC 63 ll s '^^E em or cj. - i i-dati-r- cr ^ ^ i\ s 

machine 5000 111 the pre selected u s)i t -i"'' i ui FIG 49 The fiis,t slate 
t ' . I 'i ( Hi i oiidifK n } i Hit 

thL. J 1 tl vi tt n 1 t It 1^ LRv. ot the sub tnme he ider il o 

p.-'^'-e v,n t-'is p^Uv^t . v,^ . L C ' ; the b iLe oi tie pac^tei nr ti. r 
machine can be cha"^, i u !h'=' j late 4908 A sync error, co d ii n ^ t I 

I -iitst- ill-" st<*t>. ir> 1 till -i <i R ri -Lile i-JIO ttnd a '5e( trd fcrurifn .1 t 4- 
.'uy^i-ti 1 h^Uei uisu)\c ed ih?t anv C Rf i whirr ut in V!!>i') pDi k ^ llni^-'Tlic 
lit- Tiichni lO -move out oi m sync "tatc 1<X)f- Ihe one s\n<. er-o- trTv- 1 10 
Another CRC failure of any MDDI packet wili cause a move to the two sync failure 
state 4912. A packet decoded with a correct CRC value will cause the state machine to 
return to the in-sync state 4908. 

[00308] What has been changed is to utilize the CRC value or determination for 'every' 

packet. That is, to have the state machine look at the CRC value for every packet to 
determine a loss of synchronization instead of just observing sub-fcanse iieader packets. 
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Ixi tFus coBfigiiration or process, a loss of synchronization is not detensmed using the 
unique word and |ust sub-trame header CRC values, 
[003( Til n w inieifrfxe inipkmrntabou rillows llie MOD niU'riaff linlf hi I'l o'^nzc 

ih I /dbon failures much more quickly, and, therefore, to remver from them raore 

quicldv. as well . 

[OCBP I- system moie i i7>_ i M.b 

friTTic u i -f tlient then checks ic the p c^enct e»l ihc u- 1 u rd the time it 
i-^ r I " signal Ft the unique v/^^ r I 

coi I !t 11 11 t 1 _ jhaf .1 synrhiom/fifion '■^\ < i f i - ]i t !» 
iroi'' ! L ic]<lj t'ifiii i u h d tr x'i. It v< 1 (li I i!« i>\ U tmies ( i >uOvls {]h wtit 
ti-an a lUb tt ic c 5e c-ili li the ^c'st ror tl e nniqi, r ^ nd ind citPS it not 
pie ir ot'ic vrtd, t jat the timing is irconca tie" the chert t,a j timediate'j 
declate a lo^^ ot s\ichoiii7aticn ai-d '^c^e t" the ro *a+e Ihs ptoce"- o* 

ma in S l-plti ' Ul { I L \l > o I t ■> ib ll II I. 'd !i k^Kp^tt I to 

be . u I II ll ll ( id us i i i } i .( iMini ^1 kl\ feo uo til.;. >.n 
Evnc ^\o.c fJOl 5a\xng additional timi.. v-^jtiij. ^o^. mJi^oL smi- viiurs (condtion 
normally encountered traversing through states 4910 and 4912. 
[00311] This change uses an additional counter or counting function in the cHent core to 
count sub-frame length. In one embodinient, a count down function is used and the- 
transfer of any packet that was currently being processed is interrupted to check for the 
sub-frame unique word if the counter has expired. Alternatively, the counter can count 
up, with the count being coinpai-ed to a desired maximum or particular desired value, at 
which point the current packet is checked. This process protects the client from 
decoding packets that are incorrectly received on the client with extraordinarily long 
packet lengths. If the sab-fiame length counter needed to intenrupt some other packet 
that was being decoded, a loss of synchronization can be determined since no packet 
should cross a sub-frame boundary. 

IX, Packet Processing 
[00312] Foi each type of picket discussed above that the state machine receives, it 
undertakes a partieular processing step or series of steps to implement operation of the 
interface. Forward link packets sre generally processed according to the exemplary 
processing listed in Table XU below. 
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[00313] Table XH 



Packet type 


P'acket processor state machine response 


Sub-Frame Header (SH) 


Confirms good packet, captures sub-frame 
length field, and sends packet parameters 
to a gelDLeral purpose processor. 


Filler (F) 


IgnojBs data. 


Video Stream (VS) 


Literpnets the Video Data Forniat 
Descriptor and other parameters, unpacks 
packed pixel data when necessary, 
ti-anslates pixels through the color map if 
necessary, and writes pixel data to 
appropriate locations in the bitmap. 


Audio Stream (AS) 


Sends audio sample rate setting to audio 
sample clock generator, separates audio 
samples of spKiified size, unpacks audio 
sample data when necessary, and routes 
audio samples to appropnate audio sample 
FIFO 


Color Map (CM) 


Reads color map size and offset 
parameters, and writes the color map data 
to a color map memory or storage location 


Reverse link Encapsulation (REL) 


FacilitatBS sending packtrti; in reverse 
dtrectton at the appropridie tunc Rcvi^isc 
hnk flass are exai- irinJ, ono Display 
< ' ' - V . L nt as necessary. 

'J 4t, i\ I t 1 1 II 1 M iius packets are 


Display Capability (DC) 


Sends this Ivpe oi packet when requested 
by a host u n< iiLt i c "il tlic" held 
o1 ih. ^ .Li t i 1 ! ! u q ill J , oil IKaUi 


Keyboard (K) 


Passes these nackete to arid tarn a. gencr,al 
a L;^ 1 d t i CMCc, it one is pascnt. 


Pointing Device (PD) 


F ^ .HH... ml '-.J t ) . , 

purpose processor that comimunicates with 
a pointing tj'pe device, if one is present, 
anduii- 15 dc-i e„ 


Link Shutdown (LS) 


Ktuoicisidc-ilmlv ih iK u( <ii If 11! s 
ageiteia^ pL-'iii^M-pMi' t'-Mi 


Display Service Hsqt^st and Status 

(DSRS) 


Sends this packet as "uczt i m_ 
Reverse Link Encapsulation packet. 


Bit Block Transfer (BPT) 


UUetpietv .,t< krf , u)--t>, . v'l, 
Dalei Foimai Dc " ']> <»i, d-^^r !> i e h en 
pixels to move first, and moves pixels m 
bitmap as requited. 
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Packet type 


Packet processor state machine response 


Bitmap Area Fill (BAF) 


Inten ta-- patl et paiameten fadnshtes 
piX'-K i!„h cole r mip it necess\ir> and 
writes Dixei data to appropriate locations in 
bitman. 


Bitmap Pattern FiJI (BPF) 


Imei OH 1 t ^ t . 1 -lie s ui pi U 
packed pi^d daui li rcc'^'isdry, tian&Ia'eb 
pDiels through color map if necessary, and 
V. ntes pixeJ data to appropnate locations in 
bitmdp. 


Coramunication Link Channel (CLC) 


Sends tins d 41 iir-al t ^vn'-uil 
purpose DrO'cesKOi'. 


Display Service Request (DSR) during 
hibernation 


(n tit ial-pfii.j..u»SL. piLK 1, ijui ».ot)it<.Js the 
jow-icvel functions of sending request and 
dciecis contention with linis: restarting on 

Its own. 


Interface Type Hiandoff Request (ITIIR) 
and Interface Type Acknowledge (TTA) 


May pass these packets to and from the 
general-purpose processor. The logic' to 
receive this type of packet and formulate a 
response witii an acknowledgment is 
substantially minimal. Therefore, this 
operation could also be implemented 
within the packet processor state machine. 
The resulting handoff t?cqurs as a low-level 
physical layer action and is not likely to 
affect the fimctionality or fiinctioning of 
tlie general-purpose processor. 


Peif orm Type ^ndoff (PTH) 


May act or» such packista either directly or 
by transferring them to the general-purpose 
processor, also eommanding hardware to 
undergo a mode change. 



X. Reducing the Reverse Link Data Rate 
[0Q314] It has bceii observed by the inventors that certain parameters used for the host 

link controller can be adjusted of configured in a certain manner in order to achieve a 
maximum or more optimized (scale) reverse link data rate, which is very desirable. For 
example, during the time used to transfer the Reverse Data Packets field of the Reverse 
Link Encapsulation Packet, the JVIDDI_Stb signal pair toggles to create a periodic data 
clock at half the forwai'd link data rate. This occurs because the host link controller 
generates the MDDI„Stb signal that corresponds to the MDDI„DataO signal as if it were 
sending all zeroes. The iVIDI>I„Sth signal is transferred from the host to a client where 
it is used to generate a clock signal for transferring reverse link data from the display, 
with which reverse data is sent back to the host. An illustration of typical amounts of 
delay encountered for the signal transfer and processing on the forward and reverse 
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paths in a system employing the MDDI, is shown in FIG. 50. In HG. 50, a series of 
delay values 1,5 nsec., S.O usee., 2.5 usee., 2.0 nsec, 1.0 nsec, 1.5 nsec, 8.0 nsec, and 
2.5 usee., ai-e shown near processing portions for the Stb+/- generation, cable transfer- 
to-display, display receiver, clcwk generation, sigr.al clocking, DataG+Z- generation, 
cable transfer-to-host, and host receiver stages, respectively. 
[00315] Depending on the forward link data rate and signal processing delays 

encountered, it may require more time than one cycle on the MDDl_Stb signal for this 
"round trip" effect or set of events to be completed, which results in the consumption 
nndesirable amounts of time or cycles. To: circtimvent this problem, the Reverse Rate 
Divisor makes it possible for one bit time on the reverse link to span multiple cycles of 
the MDDI„Stb signal. This means that the reverse link data rate is less than the forward 
link rate. ■ 

[00316] It should be noted that the actual length of signal delays through the interface 

may differ depending on each specific hoat-client system or hardware being used. 
Although not required, each system can generally be made to perform better by using 
the Round Trip Delay Me^iii-ement Packet to measure the actual delay in a system so: 
that: the Reverse Rate Divisor can be set to an optimum value. 

[00317] A round-trip delay is measured by having the host send a Round Trip Delay 
Measurement PacJset to the display. The display responds to this packet by sending a. 
sequence of ones back to the host inside of, or during, a pre-selected measurement 
window in that packet called the Measurement Period field. The detailed timing of tliis 
measurement ua, ui m > bed [deviously The ton. d ni- delay is used to determine the 
latc i"hich zh^ ie\cric hr,\ dat., K..a\ br ^atc \\ «a!H,-.l.d 

[003l^j The loird tup ddd\ j1 c i^j.v oien co-ms1<. o d^ic-amruz dHecli ig or 

tO!i»i.n» (he vnnv-v ol for „- J„t^ ci'ck nc..Js ,x(uni ^ i ll.e 

iojt.in^o Ik Me.i'^uKni-, ^ -^>e ei^nmn^ rt t! c tiiu t n-d - ri« 

t 0 UdL d\ft IMK t.-^poiisr- u -t. 1^ iei >^ ^ -f hyk :4 -he bostlrom 4ie J.c.-t r^-'r 
inu.i it.Fo...ioktUc-tthc e-.po si jioml he client- ouul V- ■e'-e.^'^tt . irii.Kli 'rj.;ticn o u. 
forwai-d link clock period before the measurement count was al50ut to increment. If this 
unmodified value is used to .calculate .the Reve.r5e Rate Divisor it could cause bit eo-org 
on the re¥ei-se link due to unreliable data sampling. An example of this situation is 
illustrated in FIG. 51, where signals representing MDDI_Data at host, MDD.rStb at 
host, forward link data clock inside the host, and a Delay Count are illustrated in 
graphical form. In FIG. 51, the response sequence was received from the display a 
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fraction of a forward liiilt clock period before the Delay Count was about to increment 
from 6 to 7. If the delay is assnmed to be 6, then the host will sample the reyeise data 
just after a hit transition or possibly in the middle of a bit transition. This could result jn 
erroneous sampling at the host. For this reason, the measured delay should typically be 
incrementad by one l^foie it is used to calculate the Reveise Rate Divisor. 
100319] The Reverse Rate Divisor is the number of MDDLStb cycles the hsst should 

wait before sampling the reverse liiric data. Since MDDI_Stb is cycled at a rate that is 
m& half of the forward link rate, the cdnected round-trip delay measurement needs to 
be divided by 2 and then rounded up to the next integer. Expressed as a formula, this 
relationship is: 



reverse _ rate _ divisor = RoundUpToNextlnfeget^ ^^^'^ ~ - '^^^^ ^ j 



. For the example given, this becomes.: 
reverse _ rate_ divisor ~ RoundUpToNexlInteget^~Y^ ~ 4 

[00320] If the round trip delay measurement used in this example -were 7 as. opposed to -6, 

then the Reverse Rate Divisor would td^o be equa.! to 4. 

[00321] The reverse link data is sampled by the host on the rising edge of the Reverse 

Link Clock. There is a counter or similar known eircuil. oi device present in both the- 
host and client (display) to generate the Reverse Link Clock. The counters are 
initialized so that the first ri .sing edge of the Reverse Link Clock occurs at the beginning 
of the first bit in the Reverse Link Packets field of the Reverse Link Encapsulation 
packet. This is illustrated, for the example given below, in FIG. 52. The counters 
incrcrnent at each rising edge of the IvIDDI_Stb signal, and the munber of counts 
occurring .until they wrap around is set by the Reverse Rate Divisor parameter in the 
Reverse Link Encapsulation Packet. Since the MDDI__Stb signal toggles at one half of 
the forft'ard link rate, then tlte reverse link rate is one half of .the forward link rate 
divided by the Reverse Rate Divisor. For example, if the forward link rate is 200- Mbps 
and the Reverse Rate Diwsor is 4 then the reverse link data rate is expressed as: 
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2 4 ^ 



[00322] An example showing the timing of the MDDIJJataO and MDDI_Stb sigixal lines 
in a Reverse link Encapsitlation Packet is shown in FIG. 52, where the packet 
parameters used for illustration have the values: 

Packet Length =; 1024 (0x0400) Tiim Around 1 Length = 1 
Packet Type = 65 (0x41) Turn Around 2 Length = 1 

Reveise Link Hags = 0 Reverse. Rate Divisor = 2 

Parameter CRC = 0xdb43 All Zero is 0x00 

Packet data between the Paeket Length and Parameter CRC fields, is: 

OxOq, 0x04,0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Ojcdb, OsOO, ... 

[00323] The first reverse hnk packet returned from the display is the Display Request 

and Status Packet haMiig a P ^ * ! c . t i d i j-a-ket rvpe ct 70 This packet 
begins with tlie Irvte vam: ' the first 

byre (0x07 MS 'is<Mk n '-^i- > i- I ^ nearly 

one re\ eise link clodv peiiod i I - i 1 i 1 1 i li n i r-i r lu 1 <| 1 1\ A,n 

ideal wavetorm witii zero ht St U) d sjlci, itm iii 11 i i . > n i i .loitMnine 

[0032 H IhL AIS b\L .1 ihs Parai .etcr CRC „ . . r . S i K , ..t ,i 

"nen ihj jII z*ij fielc Ihe itro'^e hom the "^c ) t ~r ' o j: r.. ..n^ bjck 

s 111 sUuhe ss)>.'H Iks ti thr mghei li'i^ u' H the ' h nt-e in i. o I fi I- 1 ue 
i-vS a choigt ijt.ir snc tnU oi 11r ih^iiu i <i\ hi iii flii.'- -^ihi'u svVjlLlie^ a ths highei 
rctc fci the icmainds^r ol I'll, titiiri. duc *c t-i. i^^z-a 'J or 1 iovelt of .h^ aa <. signal foj 

[00325] The reverse link clock for the host m at zero until the end of the Turn Around I 

period, when the clock is started to accoirmiouate the reverse hnk packets. The arrows 
in the lower portion of the figure indicate wheii the data is sampled, as would be 
apparent from the Temainder of the disclosure. The first byte of the packet field being 
transferred (here 1100CK)OD) is shown conunencing after Turn Around 1, ^d the line 
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level has stabilizeal from the host driver being disabled. The delay in the passage of the 
first bit, and as seen for bit three, can bee seen in the dotted lines for the Data signal. 

[00326] In HG. 53, one can observe typical values of the Reverse Rate Divisor based on 

the forwai'd Mult data rate. The actual Reverse Rate Divisor is determined as a result of 
a round-trip link measurement to gaarantee proper reverse link operation. A first region 
5302 corresponds to an area of safe operation, a second region 5304 corresponds to an 
area of marginal performance, vifhile a third region 5306 indicates settings that are- 
unlikely to function properly. 

f00327] The round-trip delay measurement and Reverse Rate Divisor setting are the 

same while operating with any of the Interface Type settings on either the forward or 
reverse link because they are expressed and operated on in terras of units of actual clock 
periods rather tlian numbers of bits transmitted or received. 



XI. Turn-Around and Guard TiniCiS 
[00328] discussed earlier * . ^ > 

Packet ul ij * > u ! i> f la 
designate values lor ieneths oi nme tm 
disabled bc"^rc th i-i 
Time ^ eSd prc\ iir i c ' 
ihc host d vci<i c <. mil. t>l '^i ' 
filled uth p c s^t cr pre ^L^t^d aw 



1 I it Id 1 the 
, Inr 

ire enab'cd 



Dependini 

empiric d 



[003293 



Turn Around 2 and Guard 
:h allow the display drivers to be disabled before 
:t;. li.n:.e 1 and <3uard Time 2 fields are generally 
es ror isr.gths that are not meant to be adjusted. 
>'vu:$i used, these values maybe developed nsing 
ta-aco3 10 improve operation. 
clcriDinaiion of the length of Turn Around 1 and 
d ti'ie maximum disable time of the IvlDDLData 
, i dn u d'- nk lim^ ]■> spirit c- ii ( n( CI 
where it shov tl'-at the dnvcrc talt;; about 10 t rrd.i.imLm to disable and about 2 
nsec. to enable. The minimum number of forward link clocks required for the host 
driver to be disabled is expressed according to the relationship: 

Clocks _to _(iisablefM = HostDth>erDiscthleDeh.y„„ 

InieifaceTypgFaetor^i^ 



these are the fo 
drivers m the 1 



I iwt h ir. vs 



Ihc 
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100330] The allowed value range of Tutn Afoond 1 is expressed according to the 

relationship: 

Turn _ Around _ 1 > RoimdUpToNextlnteger ^^^'^^ ~ -^^'^^^™ . interfacefypeFactorp^ j 



[00331] where the Interface Type Factor is 1 for Typp-I. 2 for Type-H, 4 for Type-DI, 
and 8 for Tj-pe-IN'. 

[00332] Combining the two equations from above, one can see that the Interface Type 

Factor tenn cancels out, and Turn Around 1 is defined as: 



[(K)333j For example, a 1500 Mbps Type-IU foctward Hnk would use a Tuiti Around I 
delay of: 



Turn _ Around _i = RoundUpToNextTnre^^er^ ISQOMbps lOn sec "j 



[00334] As the round trip delay increases, tlie timing margin improves from the point in 

time when the host is disabled to the time the display is enabled. 

[00335] The factors that determine tlie Isngdi of time geneiali> u-.^d !u i m im i ' 

iire the forward link data rate, the maximum disable tirre en t>'e Ml'--. 

the display, and the round tnp delay o( Ihe (-ominimicohoa link J'he * nkia(>u itk' 
time required to disable the aisplav driver is essentially the same as that for the hosit 
driver discussed above, iwl t. ueJiui-il i^coidmg ,o ihw ielatioai>hip: 



InterfaeeTypeFactorp^Q 



and the allowed value range for Turn Ai'ound 2 is expteasKl as: 
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TUfti _ Around ^ 2 > RamdUpToNextlnteger 



Clocks _ to _ disable j-^j^ + rotmd _ trip _d€lay + l 



I InterfaceTypeFactorpyf 



[00336] Fcwr example, a 1500 Mbps Type-in forwaitl Knk with a round-trip delay of 10 

forward luik eloclcs typSeaUy uses a Turn Around 2 delay on the order of: 



Clochi_to _ disable^j,^ ^ 1500Mbps ^^^^^^ ^ 
4 



Turn^ Around _2 > RomtdUpToNextlntega 



Xn. Alternative Reverse Link Timing 
[(X)337] While the use of timing and guard bands discussed above work to achieve a high 
data transfer rate interface, the inventors have discovered a technique to allow for 
reverse bit lengths thai are shorter than the round trip time, by changing the reverse 
timing discovery. 

[00338] As presented above, the previous approach to the timing of the reverse link is 

configured such that the number of clocis: cycles is counted from the last bit of the Guard 
Time 1 of a reverse timing paclcet until the fMt bit is sampled on the rising edge of an 
10 clock. That is the clock s!gnal{s) uised to time the inputs and outputs for the MDD 
interface. The calculation for the reverse rate divisor is then given by: 



reverse ^rate ^divisor ~ RoundVpToNextltttegeA 



round _ trip „ delay + 1 1 
. 2 J 



[00339] This provides a bit width equal to the round tnp delay which resulta in a very 
reliable reverse link. However, the reverse link has been shown to be capable of 
running faster, or at a higher dat^ transfer rate, which the inventors want to take 
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advantage of, A new inventive technique allows utilizing additional capabilities of the 
interface to reach higlier speeds. 
[00340] This is accon]4>lished by having the host count the number of clock cycles until a 
one is sampled, but with the host sampling the data line on both the rising and falling 
edges during the reverse timing packet. This allows the host to pick the most useful or 
even optimal sampling point within the reverse bit to smms that the bit is stable. That 
is, to find the most useful or optimal rising edge to sample data on for reverse traffic 
revei-se eaicapsulation packets. The optimal sampling jwint depends on both the reverse 
link divisor and whether the first one was detected on a rising edge or a falling edge. 
The new timing method allows the host to just look for the first edge of the OxFF OxEF 
OxGO pattern sent by the client for reverse link timing to determine where to sample in a 
re verse encapsulation packet. 

[00341] Examples of tlic arriving reverse bit and how that bit would look for various 
reverse rate divisors, is illustrated in FIG. 64, along with a number of clock cycles that 
have occun-ed since the last bit of Guard Time 1. In Fig, 6'1, one can see that if the first 
edge occurs between a rising and falling edge (labeled as rise/fall), the optimal sampling 
point for a revcin- > ■ ii:sor of one, the optimal sample point is a clock cycle edge 
labeled 'b', as tLal is, the only nsmg edge occuning v/ithin the period of the reverse bit. 
For a reverse rate divi&or of tv> u he not a,ai sampling point is probably still clock cycle 
leading edge 'sj' as c.clc ocI-t • hn edg^-; than 'b'. For a reverse rate divisor 

of four, the opuniu. i.mpling poir.i i3 r-roLxibU cIlca cycle edge 'd', as il is (.closer to the 
back edge of thr u I'crbe bit vhere the value has probably stabilized. 

[00,342] Retumirsg to FIG. 64, if, however, the first edge occurs between a falling and 

rising edge (labeled as fall/rise), the optimal sampling point for a reverse rate divisor of 
one is sampling point clock cycle edge 'a', as that is the only rising edge within the 
reverse bit time period. For a reverse rate divisor of two. the optimal sampling point is 
edge 'b', and for a reverse rate divisor of four the optima! sampling point is edge 'c'. 

[00343] Qiie can see that as the reverse rate divisors get larger and larger, the optimal 

sampling point becomes easier to ascertain or select, as it should be the rising edge that 
is closest to the middle. 

[00344] The host can use this technique to find the number of rising clock edges before, 

the rising data edge of the timing packet data m observed on the data line. It can then 
decide, based on whetlier the edge occurs between a rising and falling edge or between a 
falling and rising edge, and what the reverse rate divisor is, how many additions! clock 
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cycles to add to a number counter, to reasonably ensufe that the bit is always sampled as 
close to the middle as possible. 
[00345] Once the host has selected or determined, the number of clock cycles, it can 

"explore' vanous reverse rate divisors with tlie client to determine if a particular reverse 
ratf di n-ci will worl 'Hie 1 oil ( ind cbuit) can start with a di\isor of one and chei.k 
.h x_ t received from the client to dctci i ie if thu ■> »i. 

c ^e'- diti If -^he C RC % corrupt tba'a r prcbaoh . 

sanii-li _ 1 di d 1- h l i c ea - tl t - ct e j = „ ■> ) „nd try to nqoLsl a 
bttiu-v [ 1 f^tii It till- r- !L e_^Le> "J "i^c Pt H i^oirupt the dmsor can be 
uk i 1 lui I ( I i-w-it I idil! <ynii V nii patUi is decoded consectly, this 

[G034(. Itii'- mch J li cTcc^' c a^d u cLl b^caabC 'he '-^\cr^e ti ing il cjid. rot 

mn^L iro-n t"c 'an4 ro'ird f^p hnn„ ^ird'u i '^le to"- 'did li"k b'-a'^Js, tlie 
iuni inoiila f opiipisf^ to 'k<ooc r'-sr^vtid Ifiii pxi^-. '-^•"P ti th-^'e a e r'='^e'-,t" link 
UAui f)1 u t^v I ^ il t ,; li V (h m u li .jH . n ^or 

fortheliiil iiKL this nil Ifitd diK im i it i ^ ^rlu t il use link hi iddiliuii (he 
dxv'isoi SAi. d^ptn^ p 11 L tlic ^Lcl h J i j td o guiv,.a,.- an 

c'ocl r nit cijcl 1- jjtt5r theie is a grea:er pc=s.b::ity C" & 

boTipli^g e'^oi !' -^iio li 111" ii"uurt 01 c-'ocl- cvchs j" the 

rf>und inp delay. 

[0034,1 Tins mifihiH 1 ifi i }> i u. h t U 1 , m iIiIi luil ion 

p^.iinrhL-i r >p 11 tc i_h 1 l c „ t i„L 1 \ t ^ui 

data Imt" pyt^uti ill • lav^ l o gr^. ' U rin -n^ li"L al the rile thai wurl i bt I lor jusl 
one data pair. However, the data rate probably does not ne&i to be reduced to the 
previous method even with Type-TT thi-ough Type-IV for operation. This method may 
also work best if duplicated on each data line to select the ideal or an optimal clock 
sample location. If they are at the same sample time for each data pair, this method 
would continue to work. If they are at diflferent sample periods, two different 
approaches may be used. The first is to select an desired or more orlirrii^ed sample 
location for each data point, even if it is not the same for each data pair. The host can 
then reconstruct the data stream after sampHng all of the bits from the ^t of data pairs: 
two bits for Type-II, four bits for Type-Ill, and dght bits for Type-TV. The other option 
is iFor the host to inciiease the reverse rate divisor such that tlie data bits for every data 
pair call be sampled at tlie same clock edge. 
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Xni. Effects of Link JOdlay and Skew 
[00348] Delay skew on the forward link between the MDDLData pairs and MDBJLStb 

can limit flie maximum possible data rate unless delay slsew cdmpensation is used. The 
differences in delay that cause dining skew are due to the controller logic, the line 
drivers andreodveis, and the cable and connectcfrs as outlined below. 

A. Link Tin^g Analysis Limited by Skfew (MDDI Type-I) 

1. Delay and Skew Example of a Type-1 Link 

[00349] A typical interface circuit similar to that shown in FIG. 41, is shown in HG. 57 

for accommodatmg a Type-I interface link In FIG V 2\-^p>dv -r ^"piL,ai \aiues tor 
pmpagatjon delay and skew shown for each of sr-v£i il pio t-<-vn<f or mlertace stages 
of an MDDI Ty^ie-I rc,r\/a.a i„ i, si i m he.x\e.ii MTM»i_sth ,nd 

MUDI_Dpt»0 c'iU-e > ,1-, ^ r-. . > ,>Ui Mi D 

input »ti]. - -nr -|| ), , ^P^XT) s J., ^ MP Hops -,72s, 17 P iuu,l di mgc 
sl^Si ft- • - !■ ■ ' . pulilr :.^dre sLovs trfo 

cascaded Jela> l.nc-. "32a h id VdTb being used to v-h^ two dif 'ers-t proLibms witr. 
cieetmg this, 'rr'r, - r-iit -ii -h [ i.i ihv .^iuil implementation these may be combined 
.mto a single deiiiy slemcnt, 

[00350! PtiU^ I I u c>-i Kei^'-LT', 1 :ramg on a Type-I Link for exemplary sigiial 

.iiuroi:>iiijf Uitooi^h :ntctf_ie dr- ill-jitidted in HG. 58. 

[00351i The roiaJ tHa> ikew Jist is «!^t! u ^eii-' ilU liscE. o LCir<-_, rii.'i -nc njm 

of the skew m the following stages: transmitter tlic-n p TsIT « ith flip flnp- .?04, 
5706; transmitter dnver (TXDRVR) with dnvers 570S, 5710; the CABW 5702; 
e- -rur^, ■ft-' ieceniii tR>:RCsTi'! nit-^ receivers 5'"21. .ui.^ rrrp.,-i Xf^R I ^^ic 

aOCXOR) Delayl 5732a should malch or exceed Uie delay of the XOR gate 5736 in 
the RXXOR stage which is determined by the relationship; 

'fa -itiiii(- Delay J) " 'pB -maa; XOR ) 
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[00352] It is desirable to meet tliis requiraiilent so that the D input of receiver flip-flop 
572S, 5732 does not change before its clock input. This is valid if the. bold-time of 
RXFF is zero. 

[00355] The purpose or function of Delay2 is to compensate for the hold-time of tte 
RXEF flip-flop according to the relationship: 

f PD- mi^Del^yii ~^H{RXFF) 

[00354] In many systemis this will be zero because the hold time is zero, and of course in 

that case the maximum delay of Delay2 can also be zero. 

[00355] The worst-case contribution to skew in the receiver XOR sta^ is in the data- 
late/strobe-early case where Delayl is at a raaximntn value and the clock output fronoi 
the XOR gate comes as early as possible according to the relationship: 

^SKEW-msoLiSXKOR) ~ ^ PD-mmiDelayl) " ^ PD-winiXOR) 

[00356] In this situation, tlie data may change between two bit periods, n and n+1, very 
close to the time w here bit n+ '> .si,!.. -,<l 't !<■■!!•;'•-> ou> liii-llop. 

[00357] The maximum data rate fniir,nr.um l-.it periods of an MDDl Type-1 link is a 

function of the maximum skc -- :■ _=,i i h-cu^ii all t)ic dnvcrs. cable, and receivers 

in the MDDI link plus the toL • lj tne RXFf- itj.^e. Tf'e total delay skew in 

the link up to the output of the RXRCVS hU^v can b^; evi'icsseii ."S 

^SKEW-miii(,LlNK) ~ hKEW-tmiS.(TSFF} ^ SKEW-watiilWRVR) + ^SKISW-nmiiiCABLE) ^SKEW--tcsa(RXRCVR) 

and the minimum hit period is given by: 

[CS)358] In the example shovi^n in FIG. 57, fSKEW-max(IINK) = 1.4 nsec and the 
minimum bitp^od can be expressed as: 
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hrr^nm = 1. .4 + 0.3 + 0.2 + 0.5 - .2.4Ksec, 



or stated as approxiniately 416 Mbps. 



I u Et T 1" 'V ''.i tor iNiLfUi i'^ ^ 



[00359] 



lOWI 



in 



HG, 



J, ry[\ TT, m, ^ni 1 - i 



lonal. elements 



are used in the TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF (5932, 
5928 -1 'I) -uo^'- o at..Lmmrdatc the additional ^.j-vfl not --^-i y Ti r"r 59, 
exem I sii -^t t^p^^^ »alt^t 'or propagation delay ani sjceiv ar£ slnvi ^--i 1 1 I of 
sevei 1 not fssi \o o^- menace <;t„^es ot an MUDl J "dc ll trr^ l J n n acd'tinn to 
skew iti ll t d-]d> ll iv>v Ti 'vlDDLS'i ird MDnT_ri.iiaO iff'.Lii^ > i i i>e ot the 
output cio^l, thi-'.!-' is dKi sufa L>ch\(n;n both ol iliest twi -.ij f-i*- iiJ the oTlipr 
MDDI„Data ^ut.a Oat^ it thi D input of the receivei flip flop B (RXFFB) «tage 
consi stirg -f f p -'np^ '^''Jb and d9j0, is changed slightly aftei tht- <,l<xk edge bo it cian 
be sampled reliably. If MDDI_Datal arrives earlier than MDDLStb or MDDIJDataO 
then MDDI_Datal shoiild be delayed to be sampled by at least the ainjount of the delay 
skew. To aceomplish thiiS, data is delayed usiiig the Delay3 delay line. If MDDI_Datal 
arrives later than MDDLStb and MDDIJDataO and it is also delayed by Delay3 then the 
point where MDDIJ3ataI changes is moved closer to the next dock edge. This process 
detenniiies an upper limit of the data rate of an MDDI Type-II, lU, or IV link; Some 
exemplary different possibilities for the tiining or skew relation^p of two data signals 
and MPDLSth with respect to each other is illusttated in HGS. 60A, 60B, and 60C. 
[00360] In order to sample data reliably in RXFFB when MDDLPataX arrives as early 
as possible, EtelayS is iset according: to the relationship: 

^PD-mmiDelay3) ^ ^SKEW-TomiUNK) "^^H (RXFFB) ^ PD-tmx.(XOR) 

[00361] The maximum link speed is determined by the minimum allowable bit period. 
This is most affected when MDDI_DataX anives as late as possible. In that case, the 
minimum allowable cycle time is given by: 



wo 2004/110021 PCT/US2004/017579 
84 

The upper bound of link speed is then: 

^/*£)-msa(Defay3) ~ 0-inin(Deiay3) 

and given that assumption: 



[00362] in the example given above, the lower bound of the miiiimuiii bit pedod is given 
by the relationship: 



F;r-mm(towr-fe«o ^Wh IS apjpxoXiiiiately 208 Mbps. 



[00363J Tliis is much slower than the niaximum data rate that can be tised with a Type-I 
Utile. The automatic delay skew compensation capability of MDDI sigmficantly reduces 
the affect that delay skew hais on the maximum link: rate 

XIV, Physical Lay%r Entereoimeciion Description 

[0Q364] Physical connections useiful for implementiBg an interface according to the 

present invention can be realized using cdmnoercially available parts such as jrart 
number 3260-8S2(01) as manufactured by Hirose Electric Company Ltd. on the host 
side, and part number 324G-8P-C as manufactm-ed by Hiiose Electric Company Ltd. on 
the display device side. An exemplary interface pin assigrunent or "pinbut" for such 
connectors used with a Type-I/Type-II interfaces is listed in Table XHI, and illustrated 
inHG. 61, 



100355] Table Xm 



Signal Njime 


Pin 


Color 


Signal Name 


Pin 
Number 


CckT 


MDDI_Pwr 


1 


Red 


MDDI_ Gnd 




Black paired w/Rgd_ 


.MDDLStb+ 


3 






4 


Black paired w/Gi'een 


MDDLDataO+ 


? 




MDIji_Dat.aO- 


6 


Black paired w/Blue- 


MDDI_Datal+ 


7 


White 


MDDI_Datal- 


8 


Black piiired wAYhiis 








Shield 
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[00366] The shield is connected to the MDDLGad in tile host iaterfaee, and a shield 
dxain wire in the cable is coirnected to tlie shield of the display connector. However, the 
shield and drain wire are not conneGtM to the circuit giround inside of a display. 

[00367] Interconnection elements or devices are chosen or designed in order to be small 
enough for use witfi mobile conununication and comptiting devices, such as PDAs and 
wireless telephoncK. or poitablc giimc devices, without being obtrusive or anaesthetic in 
comparison to relative device size. Any connectors and cabling should be durable 
enough for use in the typical consumer environment and allow for ymall size, especially 
for the cabling, and relatively low cost. The transfer elements should accommodate 
data and strobe^ signals' that arc differential NRZ data having a transfer rate up to arotind 
450 Mbps for Type I and Type n and up to 3.6 Gbps for the 8-bit parallel Type IV 
version. 

XV. Operation. 

[00368] A summary c w J^n I steps underlalten u. -r*.(i>-,iit u. < dd p \ kis 
during operation of an miLt\ u u-, it lii i xi m i ts ol ihe ni» eiuion is sbuw ti iii I t( iS 
54A and 54B, along with an ovcryicvv ot inc. rntcrtacc apparatus processing the packets 
in FIG. 55. In these tigu.; ^ ^ 54' '2 'a .th a cete; n nation as 'o 

whether or not tlie clierj <ia ^ s it 'nupTa^on patn, leie a 

cable. This can occui thro' f'' - • ■ >' ' ic bo«' us'^ig 'o-fnvafe or 

hardware that detects the preseniuc ot cnnnectois oi t <iblo^ (« sj^jioi" at the inputs to the 
host (such as is seen foi ILSB interfaces), or othei known techinqiacs It tLcie uo 
client connected to the hos+ then it can simply entei a wail st-'tc -'t some pr^dercrmincd 
length, depending upon ne qipli jtion, go mto a hibem ■■ti •!< irooje • i 1 nacuvated lo 
await future use whit n n i<.lir requiie a usci fo lake .<i t ( • > i. i . a -» - l i h >st For 
example, when a host i-'iide on a L.mipL.iei uiif d!r\!r! au, r aiifht h.jv^ * "I" ma 
screen icon or request u piogium thaf iicti\ate-j the ho-,1 pr.xe-;nnt. t*. look lor 'ht olunt 
Again, simple plug in ot u. USB tj^pe connection, "^uch as u^ed ^or Ihs Ivot L mceriace, 
could activate host processing, depending on tlie capabilities and configuration Of the 
host or resident host software, 

[00369] Once a client is connected to the host, or visa versa, or detected as being present, 

either the client or the host sends appropriate packets requesting service in steps 5404 
and 5406. The client could send either Display Service Request or Status packets in 
step 5404. It is noted that the link, as discussed above, could have been previously shut 
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down err be in hibernation mode so tliis may not be a complete initialization of the 
Gommiinication link that follows, Onee tlie communication link is synchionized and. the 
host is trying to communicate with the client, the client also provides a Display 
Capabilities packet to the tost, as in step 5408. Tlie host can now begin to detennine 
the type of support, including transfer rates, the cHesht can accommodate. 
[00370] Generally, the host and client also negotiate the type (late/speed) Of service 

mode to be used, for esarnpla lype 1, Type U, Type U, and so tbrth* in a step 541Q. 
Oiice the service type is estahiished the host can begin to transfer iiformation, In 
addition, (he host may use Roiind Trip Delay Measurement Packets to optimize the 
timing of the communication links in parallel with other signal processing, as shown in 
step 5411. 

[00371 J As stated earlier, all transfers begin with a Sub-Frame Header Packet, shown 
being 'jTjntifcnod m iLop 5412, followed by the type of data "lers viaeo ana audio 
siic-mi piic'fs.i.-[s, h-kI nV"^ packets, shown being transfeiied iti ste'i 'i-il-. 1 lie ii'd'o 'ind 
viJio d . I II hr.v^ i- ' J jevioubly prepared or mapped -n o .u.<. kl- , nj hiu-.- ]i 1. 1. 
are iiistileJ as needed oi Jt',. e.J ti. . u. i i^qai.^d uuriihu »tl bits lui llie rijtdia 
frames. The host can send packets such as the f'orward Audio Channel Enable Packets 
lo acli" ite s-^ii.'C d;sin . - i : lunl' i d ii . r 

UMngothei patkel t-vp-s .n^usbtfc' < ' h-K li w ^ li- .r ir-wi{ Tnini Jlap Bit 

K!p-^- Tiitisie. - 1 , MI.-, <,].,, , , 

exchange data relating to <i ki <, i < . ' i i i m, i, > ,i , k 

[(XB72] During operation, one , , . , , , < I 1 the 

host or client desiring a differvn> a. ... nj.e ur :>'ps ot misrijoe m^^Lte. jt^oi extanple, a 
computer or other device communicating data could encounter loading conditions in 
processing data that causes a slow down in the preparation or presentation of packets. A 
display receiving the data could change from a dedicated AC power source to a more 
limited battery power source, and either not be able to transfer in data as quickly, 
process commands as readily, or not be able to use the same degree of resolution or 
color depth under the more limited power settings. Alternatively, a restrictive condition 
could be abated or disappear allowing either device to transfer data at higher rates. This 
being mOTc desirable, a request can be made to change to a higher transfer rate mode. 

[00373] If tliese or other types of known conditioim occur or change, either the host or 
client may detect them and try to renegotiate the interface mode, Tliis is shown in step 
5420, where the host sends Inteiface Type Handoff Request Packets to the client 
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requesting a handoff to another mode, the client sends Interface Type Acknowledge 
Packets confirming a change is sought, and the hpst sends Perform Type Handoff 
Packets to make the change to the specified mode. 
[00374] Although, iiot requiring a particuiai- order of processing, the client and host can 
also exchange packets relating to data intended for or received from pointing devices, 
keyboards, or otlier user t\'n-z n 
a'^h-^ugh such elements, "i 
tvpicallv pmcessed ii.i^q i et-i. 

" iP) iii iCiiiilUI )l I o e 

the g^i ( i \l iii. A c.^or 1^04 ->'^0t • 
1003 M At'c dut^ a^d corn i- * 

boris po^nt a deu ion mar^L 

hr- HULK i-s (J eritei cillici . hi ) mn 
a Lmk Shutdown packet loth 1 
[0037e Tl^ ^acset^: i i 

cransf i o n f ' h i. i i 
anc L ] ij ■>! li > ki 1 I 
state machiiit and ^cuei d pu i 
"^'[G Ti I ^ ^ <\ol r 
lUthci Ic ^ nijccttd t" othi^i t t n 



11 a \ wil 'Sk lui t 
de Ihce Ou^CivCt^j a e 
T 1 TO he fc( ic Tdchre 

^ ( - V \( n \d '-cuvik 1 t' c h 'it crd Jie.it it 
O'' not pddilicra data to be tiansteiied or 
" ^-iibfcr lb'" i"- bhov " m stec li2 It 
on siaie or oe shut down completely, the host sends 

11 1 lU L h I! c)i lUd 

i I tLi li ii I v,i,s wir bo 

11 ^1 c 1 ..d 1 ^IjI )] to the ho t 
1 "t"e ogic ^Isments arc conncctcG to xho 
h ^ a li ii ted i i i 

f 1 1 __eneial piotessois 5 0-1 n i 1 

nl4 not shown 'si ( 1 1 li ! 



mcTur' slcrrcats -^i othei ..c^ni^onents residing oiil ' li 

nlu 1 tiev jueta I n i-d'xi., tat not limited to *hi t. i i ^uar^e, <sn'^ 'd^o c 
chips for view display devices- 
[00377] Hk -iUH ■^so cji.l Ml luchn ni sMd- coil 1 w the eiii>iij(^ imI 

dlsiijh fj- Q d ci-s « d -,cus cd ah-n-e m n l.th n to ^uiid t n i 1 o o In u 

abbHte tilieient establishment or teimination ol communication link, and tionaier ot 
packets. 



SVI. Addendum 

[00378] In addition to the formats, structures, and contents discussed above for the 

various packets used to implement the ajrctotecture and protocol for embodiments of the 
invention, more detailed field contents or operations are presented here for some of the 
packet types. These are presented here to further clarify their respective use or 
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ppeiatiGjis tp enable those skilled in the art. to more readily understand aad malce use of 
the invention for a variety of applications. (My a few of the fields not already 
discussed ms discussed furthejF hete. In addition, these fields are presented with 
exemplary definitions and values in relation to tilie einbodiments pi-esented above. 
However, such values ai^ not fo be taken as Mmitatioiis of the invention, but represent 
one or more embodiments useful for implementing the intc;face and pivtocol. aud uot 
all embodiments need be practiced together or at the same time. Other values can be 
used tfl Pther embodiments to achieve the desired presentation of data or data rate 
transfer results, as will be undefstood by those skilled in the art. 

A. For Video Stream Packets^ 

. [00379] In one embodiment, the Display atttibutes field (1 byte) has a series of bit values 

that are interpreted as follows. Bits 1 and G select how the display pixel data is routed. 
For bit values of '00' or 'IV data is displayed for both eyes, for bit values '10', data is 
routed only to the left eye, and for bit values '01\ data is routed only to the liglit eye. 
Bit. 2 indicates whether or not the Pixel Data is presented in an interlace formal, with a 
value of '0' meaning the pixel data is in the standard progi-essive fomiat, and that the 
row number (pixel Y coordinate) is incremented by 1 when advancing from one row to 
the next. When this bit has a value of 1', the pixel data is in interlace format, and the 
row number is incremented by 2 when advancing from one row to the next. Bit 3 
indicates that the Pixel Data is in alternate pixel foimnt. This is similar to the standai'd 
interlace mode enabled by bit 2, but ths- interiacm- is vertical instead of horizontal. 
When Bit 3 is 0 the Pixel Data is in the standard progressive format, and the column 
number (pixel X coordinate) is incremented by 1 as each successive pixel is received. 
When Bit 3 is 1 the Pixel Data is in alternate pixel format, and the column number is 
incremented by 2 as each pixel is received. Bits 7 through 4 are reserved for future use 
and are generally set as zero. 

[00380] The 2-byte X Start and Y Start fields specify tiie absolute X and Y coordinates 

of the point (X Start, Y Start) for the first pLxel in the Pixel Data field. The 2-byte X 
Left Edge and Y Top Edge fields specify the X coordinate of the left edge and Y 
coordinate of the top edge of the screen window filled by the Pixel Data field, while the, 
X Right Hdge and Y Bottom Edge fields specify the X coordinate of the right edge, and 
the Y coordinate of the bottom edge of the window being updated. 
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[003S1] The Pixel Count QeM (2 bytes) specifies the number of pixels in the Kxel Data 
field beJow. 

[00382] The Parameter CRC field (2 bytes) contains a CRC of all b>tes fi:om the Packet 

Length to the Pixel Count. If Ms CRC fails to eh«::k tlien the eittire packet is discarded. 

[00383] The Pixel Data field contains the raw video information that is to be displayed, 

and which is formatted m the manner described by the Video Data Fbraiat DiKcriptor 
field. The data is transraitied one "row" at a time as discussed elsewhere. 

[0038^i] Tiie Pixel Data CRC field (2 bytes) contains a 16-bit CRC of only the Pisel 

Data. If a CRC verification of this value fails then the Pixel Data can istiU be used, but 
the CRC error count isinaremented. 

B. For Audio Stream Packets 
[00385] In on^ .mb 'd me^t, tie Audio Chanrel ID tieic ( • ->-vte) ident'ne> a pcjiticu'ar 

di'i it) '-bjnnei o vvniLji jiidKi d 't i \^ sen <>t he-ni teM e 'br uo 

c:~C.u,ltls ,p ( .Jjcil x'l . I Ji I ( i . . . * c \clr. > f 0 I . 1 1 r .1 7 

which mditatL the kit liunt i i i rill, 1 a ii Jn.nil tuitu su!> vnolcr, 

sutr^uixl iett iiau sarr l nJ. t,i.^i i^l-., >.-->j t ^1 x..!) uJi ^in ii !:i*,aiaeo* 

15^ ird3c„ts« t;:jit fie ^jrgls stieam ot digital audio sem^ies i^ 'i l " ^ oh hz :cfr fion.: 
d'ld ngb fiont c ian"e'' Tli- ■ • '"^^ i., 'h^if. ■•Lit-u.K.I I isedfor 
«• iCf ' ( ii 'lut 'Ul '00, p M ' , II •I'-.d i>n ""l \, (> 

1 I 1 ii ii 1 < I 1 ( u J ace gt,nerdte& warning tones. V^alaes foi the ID 
I ' and 255 are cunrently leserved for use where new 

dcsigiiii desire addiuonal aesignations. 
[00386] The Audio Sample Count field (2 bytes) specifies the number of audio samples 

in this packet. 

[00387] The Bits Per Sample and Packing field contains 1 byte that specifies the pacing 

format of audio data. The format generally enaployed is for Bits 4 through 0 to define 
the number of bits per PCM; audio sample. Bit 5 then specifies whether or not the 
Digital Audio Data samples aro packed. As mentioned above, FIG. 12 illustrates the 
difference between packed and byte-aligned audio samples. A value of '0' for Bit 5 
indicates that each PCM audio sample in the Digital Audio Data field is byte-aligned 
with the interface bjte boundary, and a value of '1' indices that each successive PCM 
audio sample is packed up against the previous audio sample. TMs bit is effective only 
when the value defined in bits 4 tlwougb 0 (tlie number of bits iper PCM audio sample) 
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is not a multiple of eight. Bite 7 through 6 are researved for use where system designs 
desire additiraial designations and arc generaj]y set at a value of zero, 

[00388] The Audio Sample Rate field (1 byte) specifies tlie audio PCM sample rate. The 
format employed is for a value of 0 to indicate a rate of 8,0(X) samples per second (sps), 
a value of 1 indicates 16,000 sps., value of 2 for 24,{M0 sps, value of 3 for 32,000 sps, 
value of 4 for 40,000 sps, value of 5 for 48,000 sps, vahie of 6 for 1 1 ,025 sps, value of 7 
for 22,050 sps, and value of 8 for '44,100 sps, rjL':>f:*ivc'v. with values oi U thicnah la 
■viii^i fi-^-ii s f I foL future use, so they are currc 

[0O3P.9] 'I Ik raiunr'.-r CFC field (? bytes) u.n p.., CRr of ill Hyfet bom the 

ViiCla Length rn rhc Aiid o Sinnpl.* b';ii<, !! \\u-i CRT Ttij^ to rlito'< qppio^.jiHlt ly I'f-eii 
the enure puckct is dT.cardca. Ih-., n-.,'irnl Kndio Data field cor.trauH the irw nudio 
samples to be played nnd i3 .isualh m tnc torm of j. hnsar Icrmat as unnigned integers. 
The Audio Data CRC field (2 bytes) contain a i6-bit CKC of only the Audio Data. If 
this CRC fails to check then the Audio Data can still be used, but the CRC error count is 
incremented. 

• C. h or User-Defined Stream I'atket s 
[00390]. In one ejiJsQdiment, the 2-bMo ^ ^ ■ ^ > ■ , he rsc'i i i u i 
particular user defined stream Tb*^ "■' * ■ , . r> 5> km ■! ^.I'a- uLi- xn] cLiLt 'ii I' t'j 
fields bfe t}i'V A]y dof 'Kd h> Lt e Tvl!")! ?! « u.i)...rii' n!a'-U'.i'.t"!r' T'k ?-hyi'c Stteaoi 
Parameter CRf twld ; . in n-, ,i I;, ; ,, C li'^ , ' ' > ^ <it ti i. -^tK-aiit pdUiJiieSkjr ' 
slartir^ r_'ir the . . ^i L: ' ^ - . Lf Ihis CRC t^.K to chock 

then the <.ntne packet ss di-,i. jaeu. O's 2'bYt>; Mr.t in LWtd CRC held contamfc a CRC 
of only the Stream Data. It this CRC fails to check appropriately, then use ot the 
Streati Oru <• oiilional d^.x iislirsu; thi^ n'({U!u .m nt^ of lli"^ -^tipln ^ >i "[T.-^'fje 
stream JLts; c»ir»tmgo^ni- <.n the (T'tC being cood gcrciJh loquire"; that i> q, t lU 
be buliered until the CRC is confirmed as being good. The CRC error count is 
incremented if the CRC dees not check. 

D. Fwr Color Map Packets 
[00391] Ttie Color Map Data Size field (2 bytes) specifies the total number of color map 
table entries that exist in the Color Map Data in this padket. In this embodiment, the 
number of bytes in the Color Map Data is 3 times tlie Color Map Size. The Color Map 
Size is set equal to zero to send no color map data. If the Color Map Size i@ »ero then a 
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Coktr Map Offset value is generally still sent but it is ignored by the display. The Color 
Map Offset field (2 bytes) specifies the offset of the Color Map Date in this paqlcet from 
the beginning of the color map table in the display device. 
[00392] A 2-byle Parameter CRC field contains a CRC of all bytes from the Packet 
Length to the Audio Coding byte. If this CRC fails to check then the entire packet is 
discarded. 

[00393J For the Color Map Data field, each color map location is a 3~byte value, where 

the first byte specifies the magnitude of blue, tiic second byte snecilles !he miijiniludc of 
green, and the third byte specifies the magnitude of red. The Color Map Size lield 

■ specifies The number of 3-byte color map tabic items that exist in the Color Map Data 

■ field. If a single color map cannot fit into one Video Data Format and Color Map 
Packet, then the entire color map may be specified by sending muitipie packets witli 
different Color Map Data and Color Map Offsets in each packet 

[00394] A 2-bj4e Color Map Data CRC field contains a CRC of only the Color Map 

Data. If fbis CRC fails to check then the Color Map Data can still be used but the CRC 
error count is incretnented. 

E. For Keverse Link EncapsnlaUon Packets 

[00395] In one embodiment, the Revci-se Link Flags field (1 byte) contains a set of flags 
to request information from the display. If a bit(for example, Bit ITi i- sel to fie {"'itrn 
the host requests the -specified irifomiation from the display using LheDi-inlj> (".ipal'-jhtT 
Packet, If the bit is zero then the host does not need the information Iruri nc cLp ay. 
The remaining bits (here- Biis 1 through 7) are reserved for fuUirc use and .irj ci m zero. 
However, more bits can be used &s desired to set flags for the reverse link. 

[00396] The Reverse Rate Divisor field (1 byte) specifies the number of MDDI_Stb 

cycles that occur in relation to the reverse link data clock. The reverse link data clock is 
equal to the forward link data clock divided by two times the Reverse Rate Divisor. 
The reverse link data rate is related to the reverse link data clock and the Interface Type 
on the reverse link. For a Type I interface the reverse data rate equals the reverse link 
data c lock, for Type II, Type ID, and Type IV interfaces the reverse data rates equal two 
times, four times, and eight times the reveree link data clock, res|Kctively, 

[00397] The Turn-Aronnd 1 Length iield (1 byte) specifies the total number of bytes that 

are allocated for Tum-Around 1, The recommended length of Turn-Around 1 is the 
number of bytes required for the MDDI_Data drivers in a host to have the outputs 
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disabled. This is based on tlie diitpot disable time discussed above, tiie forward liiik 
data rate, and the forward linlc interface Typ^ selection being used. A mora cpmplete 
description of the setting of Turn-Around 1 is given above. 
[00398] The Turn-Around 2 Length field (1 byte) sjpecifies the total number of bytes that 
are allocateid for Tiirn-Arduiid. The recomnlerided lengdi of Turn -Around 2 is the 
number of bytes reqiured for the lvn>DI_J)ata drivers in the Display to disable their 
outputs plus the round-trip delay, A description of the setting of Turn-Around 2 is 
given above. 

[00399] The Parameter CRC iield (2 bytes) contiiins a 16-bit CRC of all bytes from the 

Packet Length to the Tum-Around Length. If this CRC iiails to check then the entire 

packet i& discarded. 

[0040d] The All Zero field (1 byte) is set equal lo zero, and is used to ensure that all 

VOD< Diit3. ignJ'^ are ^^ne zero s^i'^ pro'- *o J-'iabhng the nnr tliiNtr., anrti tnc 
first Guard Time Deriod, 

[00401] ill. i Jin-A t).,i (I 1 f,eld is used loi - ^ i U.Umi 1. 1 . iM n m )i .n n o u^A 

it ,1 nth I .1 b,u. s "ipeafied by the Turn An i 1 i ^1 . i < ii.akj i i u i <l n 
th s tiwld lo JLh the MDDI_Data line drive *' . 1 ^xt d . itL > kit 'h. iix 
dr.\crs ;n the chcnt;di3ck:, J ar-.- enabled. Tr ' . ^ jjt n Jruers 

dunng bit 0 of Turn Aiourd 1 and the chent (display; enab.es its hne dnvert 
ipy^'ediatelj <vi \k li-l bit of Tum-Around L The MDDL. Stb agnal behaves as 
though t'lv^ I 111 -I I V ivviKdll zeros 

[00402) Th^. ticld containb a '"ene tts being 

tiji'-terred Itjtj lI . ^ i-v^i As stated eorher, PiUer pa^kc b tori. i,o fill the 
remaining space that is not used by other packet types. 

[0CMO3] Tum-Around 2 field is used for establishing the second turn-aroimd period. The 

number of bytes specified by the Tum-Around Lengtii parameter are allocated by this 
field. 

[00404] The Driver Re-enable field uses 1 byte that is equal to zero to ensure that all 

MDDI_Data signals are re-enabled prior to the Packet Length Field of tiie next packet 

F. For Display Capability Packets 
[00405] Itt one embodiment, the Ptotocol Version field uses 2 bytes to specify a protocol 
version used by the client. The initial version is set equal to zero, while the. Miniinuni 
Pnotcwol Version field uses 2 bytes to specify the minimum protocol version that the 



wo 2004/110021 



93 



PCT/US2004/01757<> 



client can employ or mierpret. The Display Data Rate Capability field (2 bytes) 
specifies the maximum data rate the display < an receive or dj- i r d link of the 
interface^ and is specified in the form of megabits per secom (T F e Interface 

Type Capability field (1 byte) specifies the interface types. Mm i - '-h i| o ted on the 
forward and reverse links Tlus is cui lentlv indu atcd b> ^.1 li <- )l t 1, or Bit 2 
to select either a T\'pc i 

and Bit 3, Bit 4, or fill . Ic 
revose link, respectively, witf L • i j " i-*^ „ ,p 
Width and Height fields; {?bv -) - n >} ^ k <} ^ , i u n ,( 't.L 

[00406] The Moi o-iiiOinp ^ If ii^i [f* i i drj^f , t- '-(di)',pt( U he .unl-e i of bus 

of resolution that 'ic d sp'ijtd n i iri net "i-cm-^ ^'>nn<t b a d rinnot use a 
monochrome toTna' Uicn 'i. \£i r set at zero Bit / t loach 4 aiC iwserved for 
future use ami h b.t ^ m Bi* ^ ih^o u defi le ihe "nax.rrun number of 
bits of grayscale tliat can cM^t io ch ni\ Ti^-^e tout bits make it possible to 
specify value t i > i- i ^ i-,/u»(l r. o k< ar -i! e format is 

not supported bv me aispiav. 

[G0407] TheC^Lii. d j Id (3 bytes) specifies the jiiaximajii numSer of table 

items that es^s-^ n ^ able m the display If the display cannot use the 

colormap fori i u l r i i -*io 

[G0408J The RCiP. q v e d — ^ >- itps. the number of bits of resolution 

that can be disp avul ,n RCiJ'. i.i u n ilio display cannot use the RGB format then 
this va;lue is eqaa^ to zero ihe R-^E L suability word is composed of three separate 
unsigned vah e-- 'lui^ Bi r --"i^ne the max-'mu'n -"umtt,! of dus of blue, 

Bits 7 through -i c "i the „ > ^ ^ >f bitt, o \2, e-^i jna bi II through 8 
define the maximum number of Dits of rea m each pixel. Currentlv. Bits 15 through 12 
are reserved for future use and are generally set to zero. 

[00409] The Y Cr Cb Capability field (2 bytes) specifies the number of bits of resolution 

that can be displayed in Y Cr Cb format. If the display cannot use the Y Cr Cb foi-mat 
then this value is set equal to zero. ITie Y Cr Cb Capability word is composed of three 
separate unsigned values where: Bits 3 through 0 define the maximum number of bits in 
the Cb sample, Bits 7 through 4 define the maximum number of bits in the Cr sample, 
Bits 1 1 through 8 define fiie maximum, number of bits in the Y sample, and Bits 15 
through 12 are currently reseiTed for future use and are set to zero. 
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[00410] The Display Feature Capability Indicators field uses 4 bytes that contain a set of 

flags that indicate specific features in the display that are supported. A bit set to one 
indicates the capability is supported, and a bit set to zero indicates the capability is not 
li 1 1 1 I 1 i i<- t Bil 0 mdjcates whether or not Bitmap Block Tiansfei Packet 
fpj ki v-pi 7J'> supported The value for P.it* i| md 1 indx ate whether or not 
Biiniap Area Fill Packet (packet t>pe 72), Bi Mil (packet type 73), 

o' Commumcation I -"it- Data Channel Pi^ ^ ^.ix i^pe M), respectively Eie 
sapported I he v^'i e _ s < e hdr x not the display has the cap ibil " 

niaVe one color t*- i^'-ji i -i i v n i m\s Hit <ind 6 indicate if the ni'-p .^v . cu 
d ^tps ^ dco ddio ()! L ci o tlAc ifi III !■> „ 'u 1 u It spei int ]% find rl i vrtlm fot B " 
ifdi fiks it the di'^p u cai viii i - "i 'iii \ idp~. '=:trerm .roi.i a <.fTi't ] Ihe \aliie 
tor ^ 11 in 1^ r . L ' V v^'i^n'- con m^n cat iv c.tl e with a iicirtiDjj; 
dc\ cc I d rjii i.eia aiil I., i - Mn^Tir; l'c ce Data Fa J e^^s or v ith a 1 ejboaid and 
, in ,pnd nsd i«>^ive i^ejlM 'U ' i i i i, r |Vv.ts'el> 'Mf- i'^ tliTi>"iyi "t are 

UJrrfcriih )< iivui 1 UlU > ^ n •> ^ ^ sK I- t <. U jOr,,4l t ^isil i r:> 

and oje ge. ir i, r . 
■ [0041 r Tie Dh^ L \ .d^t I ai Rd. t il s d vl -vtel >.pcc iiv>s £i-,c maxiiruni 

video frame update capability of the display in frames per second. A host may choose 
to update the image at a slower rate than the value spepified in this fidd, 

[00412] The Audio Buffer Depth field {2 bytes) specifies the depth of the elastic buffer 

in a Display which is dedicated to each audio stream. 

[00413] The Audio Channel Capability field (2 bytes) contains a group of flags that 

indicate which audio channels are supported by the display (client). A bit set to one 
indicates the channel is supported, and a bit set to zero indicates that channel is not 
supported. The Bit positions are assigned to the different channels, for exiimple Bit 
positions 0, 1,2, 3, 4, 5, 6, and 7 indicate the left front, right "front, left rear, right rear, 
front center, sub-woofer, surround left, and surround right channels, respectively. Bits 8 
through 15 are currently reserved for future use, and are generally set to zero. 

[00414] A 2-byte Audio Sample Rate Capabihty field, for the forward link, contains a set 

of flags to indicate the aadio sample rate capability of the client device. Bit positions 
are assigned to the different rates accordingly, such as Bits 0, 1, 2, 3, 4, 5, 6, 7, and 8 
being assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 
44,100 samples per second (SPS), respectively, witii Bits 9 through 15 being reserved 
for future or alternative rate uses, as desired, so they are currently set to '0'. Setting a bit 
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value far one of these bits to T indicates that that partieular sample riate is supported, 
and setting the bit to '0' indicates lliat that sample rate is not supported. 

[00415] The Minimum Sub-frame Rate field (2 bytes) specifies the mimmiim sub-frame 
late m frames per second. The minjirai ^ C« i r,i ] laie I<re[>s tht di&play status update 
rate sufficient to read certain sensors or pomling d£.vice.R m the display. 

[00416] '* 2 b-yt. San p L ^ 1 - C.cct lit hJ , i t li. i l n 1 th.. to iUm% i 

set ofildgi. tra ird t l go i ip ^ u c cj n o a ii i p-oi n the client 
device. For (.u ju t o t l IZLI a l i-n _t: i e ii r piaie is cunfiguied tu 
minimally i.uppnrL ji 1 >■ n ro r f i p r > d i f i < Hons for this field 
ari? oS<;f£,ncd lO Ut i !i . i (■>, 7, ijud ! 'oi 

cxsmpl.%bci-piH.-i Is.r.pr t , ^ (' > S' ( ',1! ' OU mi, ! 1 /j;-, 

2i,0D'J, ana 4!,lU0 sampi^t per <-cccnc' (M-'S) rc-pccf'.eh' Hilh Bits L> l.^.rcuah Id 
Dcmg nisf^rNcd l">r f"tL'rc or d^'p^ ifi c r.ic iis-<f, di dcb-^a^d, « j "ics « L'rrcTiv b'-t 'o 
'0'. Setting a bit value for one of these bits to 1' indicates that that particular sample rate 
is supported, and setting the bit to '0' indicates that that sample rate is not supported. If 
no microphone is connected then each of the Mc Sample Rate Capability bits are set 
equal to zero. 

[00417,1 The Content ft-otection Type field (2 bytes) contains a set of flags that indicate 

the type of digital content protection that is suppoited by the Display. Currently, bit 
position 0 is used to indicate v/hei) DTCP is supported and bit position 1 is used to 
indicate when HDCP is supported, with bit positions 2 through 15 being deserved for 
use with other protection schemes as desired or available, so they ate currently set to 
zero. 



G. For Display Request and Status Paekets 

[00418] The Reverse Link Request field (3 byte) specifies the nrarriev of bytes the 

display needs in the reverse link in the next sub-frame to send information to the host. 

[00419] The CRC Error Count field (1 byte) indicates how many CRC errors have 

occutred since the beginning of the media-fxanac. The CRC count is reset when a sub- 
frame header packet with a Sub-frame Count of zero is sent. If the actual number of 
CRC enrors exceeds 255 then this value generally saturates at 255. 

[00420] The Capability Qiange field uses 1 byte to indicalE a change in the capability of 

the display. This could occur if a user connects a peripheral device such as a 
microphone, keyboard, or display, or for some other' reason. When BitsI7:0] are eqiwil 
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to 0, then the capability has not changed since the last Display Capability Packet was 
sent. However, when Bits[7:0j are equal to 1 to 255, the capability has changed. The 
Display Capability Paclcet is examined to detemiine the new display characteristics. 

BL For Bit Block Transfer P£tckets 

[00421:] The Window Upper Left Coordinate X Value n_ I til ii-,e 2 bjtes 

each to specify the X and Y value of the coordiaatc^ - ,j of the 

window to be moved. The Window Width and Height iicMs _^ . no spec ify 

the width aiwi height of flte window to be moved. 'Utc Wii J. s -h. r < r. i m A-ia Y 
Movement fields use 2 bytes each to specify the number of pixeK that ih- wnK'nw )s to 
be raoved horizontally and vertically, respectively. Typically, these coordinates are 
configured such that positive values for X cause the window to be moved to the right, 
and negative values cause movenaent to the left, while positive values for Y cause the 
window to be moved down, and negaitive values cause upward movement. 

■ L For Bitinjtp Area Fill rackets 
[00422] Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to 

specify the X and Y value of the coordinates of the upper left comer of the window to 
be filled. The Window Width and Height fields (2 bytes each) specify the width and, 
height of the window to be filled. The Video Data Format Descriptor field (2 bytes) 
specifies the format of the Pkel Area Hll Value. The format is the same as the same 
field in the Video Stream Packet, i'he Fixsl Area Rll Value field (4 bytes) GOiitains the 
pixd value to be filled into the window specified by the fields discussed above. The 
format of this pixel is specified in the Video Data Format Descriptor field 

J. For Bitmap Pattern Fill Packets 
r00423] Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to 

specify ih^ X md Y value of the coordinates of tiie upper left corner of the window to 
be fiiied. The Window Width and Height fields (2 bytes each) specify the width and 
height of the ivindow to be filled. The Pattern Width and Pattern Height fields (2 b>tes 
each) specify the width and height, respectively, of the fill pattern. The 2-byte Video 
Data Format Descriptor field specifies the format of the Pixel Area Fill Value. EEG. 11 
illustrates how the Video Data Format Descriptor is coded. The format is the same as 
the same field in the Video Sheam Packet. 
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[00424] Ttie Parameter CRC field (2 bytes) contains a CRC of all bytes iiom the Packet 
I-ength tp the Video Format Descriptor. If this CRC fails to check then the entire packet 
is discarded. The Pattern Pixel Data field contains raw video iiifonuatioii: that specifies 
the fill pattern in the format specified by the Video Data Format Descriptor, Data is 
packed into bytes, and the fiist pixel of each row must be byte-aligned. The fill pattern 
data is transmitted a row at a ti.me. The Pattem Pixel Df.i» CRC field (2 bytes) contains 
a CRC of only the Pattern Pixel Data. If this CRC fails to check then the Pattem Pixel 
Daita can still be iLsed but the CRG etroc count is itjcremented, 

K.. CoMinunication link Data Chaiinel, Packets 
[00425] The Parameter CRC field (2 bytes) contain a IS-bit CRC of all bytes from the 

Packet Length to the Packet Type. If this CRC fails to cheek then the entire packet is 
discarded. 

[00426] The Communication T ii k i"> ' i f-i' O'l n"'- 'J)e dnt'i tjora Ihe 

communicatioTi channel, Thi^ aatu is oiinpl> ii > .j on lo .h om -vUi'g • ctnv i'l the 
display, 

[00427] The Communication Link Data CRC . J J ■ U hi CRC of 

only the Communication Link Data. It this *^ <' > lunicaUon 

Link Data is still used or useful, but the CRC error i-vuvA li iriciuii.;n'ed 

L. For iDterface Type Handuff Request Paeliiets 
[00428] The Interface Type field {1 hyte) specifies the new interface type to use. The 
value in tinis field s^cifies the interface type in the following manner. If the value in 
Bit 7 is equal to '0' tte Type handoff request is for the forwaid link, if it is equal to '1', 

then the Type handoff request is for the reverse link. Bits 6 through 3 are reserved for 
future use, and are generally set: to zero. Bits 2 thtx>ugh 0 are used to define the 
interface Type to be used, with a value of 1 meaning a handoff to Type-I mode, value of 
2 a handoff to Type-II mode, a value of 3 a handoff to Type-Ill mode, and a value of 4 a 
handoff to Type-IV mode. Tiie values of '0' and 5 through 7 are reserved for future 
designation of alternative modes or combinations of modes, 

M. For Interface Type Acknowledge Plackets 
[00429] The Inteifaee Type field (1 byte) has a value that condSrms the new interface 
type to use. The value in this field specifies the interface type in tlie following manner. 
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If Bit 7 is equal to '0' the Type handoff request is for the forward link, alternatively, if it 
is equal, to 'V tiie Type handoff neqxiest is for the reYerse link. Bit positions 6 through 3 
ai-e currently reserved for use in designating other handoff types, as desired, and are 
generally set to zero. However, bit positions 2 through 0 are used define the interface 
Type to bs used with a value of '0' indicating a negative acknowledge, or that the 
requested handoff cannot be performed, values of 1 '2', 3', and '4' indicating hatidoff to 
Type-I, Type-n, T>i>e--III, and Type-IV modes, respectively. Values of 5 through 7 are: 
reserved fisr use with alternative designatioris of modes, as desired. 

N. For Perform. Type .Handoff .Packets 
[00430] The 1-byte Interface Type field indicates the nc\\ ir.trrtucc t>pc to u"c Ihc 

value present in this field specifies the: interface type oy iir£,t using the value i>f Bit to 
determine whether or not the Type handoff is lor tic io^^^ did or le^ erse 'in A value 
of '0' indicates the Tjpe handoff request is foi li-e Mii'Aard hnJ' and :« ^"ilne o< V the 
reverse link. Bits 6 through 3 are reserved foi tjaiiv ast. r.tul .,■=; ^>bhh -k jy . t a") -.et 
to a value of zero. However, Bits 2 thnoughO are ubedtu define ii-,ei.,t^ilr < ! i l t.e 
used, with the vahies 1, 2, 3, and 4 specifying the use of handoff to Tvpe-i. Tjpe-IL 
Type-in, and Type-IV modes, respectively. The use of values 0 and 5 through 7 for 
these bits is reserved for future use. 

O. Foi- Forward Audio Channel Eiiable Packets 
[00431] The Audio Channel Enable Mask field (1 hyte) contajna a sroup of f;ags ihat 

indicate which audio channels are to be enabled in a client. A bit set to one enables the 
corresponding channel, and a bit set to zero disables the corresponding channel Bits 0 
through 5 designate channels 0 through 5 which address left front, right front, left rear, 
right rear, front center, and sub-woofer channels, respectively. Bits 6 and 7 are reserved 
for future use, and in the mean time are generally set equal to zero, 

P. For Reverse Audio Sample Rate Packets 
[00432] The Audio Sample Rate field(l byte) specifies the digital audio sample rate. 

The values for this field are assigned to the different rates with values of 0, 1, 2, 3, 4, 5, 
6, 7, and 8 being used to designate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 
U,025, 22,050, md 44,100 samples per second (SPS), respectively, with values of 9 
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through 254 being reserved for ose with alternative rates, as desired, so they are 
euTrently set to 'Q\ A, value of 255 is Uised to disable the reverss-link audio stream. 
[00433] The Sample Format field (1 byte) specifies the format of the digital audio 

samples. When Biis[]-OJ Mil < ' ,\ 

when they are equal to ] <■' ^ ^ ' - - i r i- ! i ' 

arie equal to2. the dtgifai atiuK. ^hmplc^ j(c m A Law > ^ti .i > ihi? ? tir ir-^r- ,rd "o 
alternate use in designating audio forirmts, ab dcbncd, and uil ^xucialiy sU equal to 
zero. 

Q. For The.Bigital Conteot Protection OTcrhead Packets 
[004:^4; Tin.; Coiiici't Pi4>iocliO,i Tjfp.' Held H '.}te) specifies the digital content 

protection incthod thar is u^od A va'.Tie of '(>' i.-iflVates Digital Transmission Content 
Protection {DICV) \\'h\\c a « a!u^ of ! nidicjfe-. High-bandwidth Digital Content 
Protection i\s:ern (i'^uC^') 1 ."e value r^n^e ot 2 through 255 is not currently specified 
bi-t is .r's-r\i"! .'di Jilternafive protection schemes as desired. The Content 

?r<ii{(.Hii . . t;es field is a variable length field containing content 

protection nicssaues setil hi 'tween the host and client, 

R. 1 or Thr 1 run,' T3»r-;nt Cctor l^nabie rackets 

[00435] I he I ranstjiirent Color Enable field (i byte) specifies when transparent coloi" 

mode is enabled oj dis^il.jvd If Bit 0 is equal to 0 then transparent color mode is 
disabled, if it is equal to 1 then transparent color mode is enabled and the transparent 
colcj 13 specified b> the following two parameters. Bits 1 througli 7 of this byte are 
reserved for future use and are typically set equal to zero. 

[G0436] The Video Data Fomat Descriptor field (2 bytes) specifies the format of the 

Pixel Area Fill Value. PIG. 11 illusfi-ates how the Video Data Format Descriptor is 
coded. The format is generally the s.ame as the same field in the Video Stream Packet. 

[00437] The Pixel Area Fill Value field uses 4 bytes allocated for the pixel value to be 

filled into the window specified above. The fonnat of this pixel is sijecified in the 
Video Data Fcamat Descriptor field. 
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S. For The Round Trip: Delay Measurement. Packets 
[00438] In one emtmdimeftt, the Paratneter CRC field (2 bytes) contains a 16-bit CMC of 

all bytes fi:ojm the Packet Length to the Packet Type. If tliis CRC fails to check then the 

entire packet is discarded. 
[OM'.K 1 he . byte) cont^im zeroes to ensoie tl rV c.ll MDDl Hata signals 

in the ^l,- ^ disiblmg the line dnvcr^. djn'^ti 'nc ^'t^t Cuard Tune 

penod. 

[004' !(< Thf^n iitlTur - i-i - h 'tes) c- iisfd to *sl)<^-"> i-" In dm eiMfi 

th^ 'KM tc disrtMt 1.- »rt tin iitit' JhM;is ii. ,h= di" t (Ji^p' ly) div tm\ •* I Tb- ho-,t 
di^iblcs (f? MDDI Para hnc dr vci* diir.ng hi oi Gi.a d ^ra. ! iud t\c Doila\ 
enables its i'nc drivers irrmediatcly aftei the last bit ot Oua d limc i 

[00441 Ihe Njed3uie^pei t ''e-'od d is a ^512 b^-te iidow ii. io allow the Dispi^^, to 

le'.iii-Mii J (!\rf Oxlt, uv() 111 ifri qi itai^ f^i- j -tl 1'=' ioru-iio ii'v (h'-nie 

iiiiiijujiatblv il titt li till I I R jn.li I it ] uii d Uii> u pdiist, be 

received at a hO'St at precisely ihe round uto deiav ot die Iiiuc alter the beginning at the 
first il 1 111 Mi.vui ' - ; . \]>1)1 Ai 1 s ne c-i'' 2"? ir the 

Di&pLi aie di -.abkd iimnf - o Ji ill- d Ovil Ox If ft ffO 

iefiDons.e iroto, toe Display. 
[00442. Thexalueiri h (n I ' ii r . I ) J( s ( 1 i N J,i I t iik 

dmen to di'-aM ! i i i l.o. j .ra 1 ^ Gua d 1 ii i, „ i I. Wh 

present but is only required when tne round inp delav is al the mammum fcimounr. that 
can be measured in the Measurement Period. The Client disables its line drivers during 
bit 0 of Guard Time 2 and the Host enables its line dii%'ers immediately after the last bit 
of Guard Time 2. 

[00443] The Driver Re-enable field (1 byte) is set equal to zero, to ensure that all 
MDDljData signals are re-enabled prior to the Packet Length Field of the next packd:. 



T. For The Forward Link Skew Calibration Packets 
[00444] In one embodiment, the Parameter CRC field (2 bytes) contains a 16-bit CRC of 

all bytes from the Packet Length to the Packet Type, If this CRC fails to check then the 
entire packet is di&earded. 
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[00445] The Calibiation Data Seqiienee .field cOMains a 512 byte data sequence that 
causes the MDDI_Data signals to toggle at every data period. During the processing of 
the CalitH-ation Data Sequence, the MDDI host controller sets all MDDI_Data signals 
equal to the strobe signal. The display clock recovery ciixntiit sIi- Td ii^e -ii-y 
MDDI_Stb rather thitoNIDDI..StbXojlvnDDrDataO to recover tl-c;d'i n.-. i .^'^'r- 1,- 
Calibration Data Sequence field is bv;." - .r , ipi (.i 

the phaau ol the MDDL £.b : _-. -\ -h? «..,:ib.ii:ion i.\ra 

Seqiirti. ^ hzK [I c C-ii-bruion Da-.^ Stqtcue " ■]! j;rn^r„llv be one of the following 
based on the inleriacc Type- bomg used when this packet is sent: 

Type I •- Oxaa, Oxaa ... or 0x55, 0x55... 
Type n - Oxce, Oxcc ... or 0x33, 0x33. . . 
Type in - Oxf 0, OxfO ... or OxOf, OxOf . . . 
Type IV - Oxff , 0x00, Oxff. 0x00 ... or 0x00, Oxff, 0x00, Oxff . 

[00446] ■ An example of the possible MDDLDala and MDDI _Stb wavertaiiiii Im both the 
Type-I and Type-II Interfaces are shown in FIGS. 62A and 62B, respectively. 

XVIL Concliision 

[00447] While various emboli! I -t '< 11 pi— r f ii>»''"iim<«!i hti\c been described above, 

it should be understood that rh^y bait- (letn ptest-ntcJ hy vvav u> (.Sample only, and not 
limitation. Thus, the breadth and scope of the present invention should not be Mmited 
by any of the above-described exemplary embodiments, but should be defined only in 
accordance with the following claims and their equivalents. 



What is claimed is: 
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CLAIMS 

1. A digital data interface for transferring digital presentation data at a high rate 
between a host device and a client device ovea: a communication path comprising: 

a plurality of packet stritctures linked together to form a cornmunication protocol 
for coaimttnicating a pre-selected set of digital control and presentation data between a 
host and a client over said conwrimucation path; and 

at least one link controller residing in said host device coupled to said client 
through said commanications path, being cdnfigored to generate, transmit, and receive 
packets fomiing said eommunicstiens protocoL and to form digital presentation data 
into one or more types of data packets, 

2. The interface of Claim 1 further comprising said packets grouped together 
within media frames that ai-e communicated between said host and client having a pre- 
defined fixed length with a pre-determined number of said packets have differing and 
variable lengths. 

3. The interface of Claim i iunher uompiiaing a Sub-frame Header" Packet 
positioned at the beginning of U'aiisfers of packets from said host. 

4. The interface of Claim 1 vvherein said link controller is a host link controller and 
further comprising at least one client link controller residing in said client device 
coupled to said host through said communications path, being configru-ed to generate, 
transmit, and receive packets forming said communications protcKol, and to form digital 

presentation data into one or more types of data packets. 

5. The interface of Claim 1 further comprising one or more Video Sti«am Packets 
for video type data, and Audio Strcairi Packets for audio type data for transferaing data 
from said host to said client over a forvv'ard link for presentation to a client user. 

6. The interface of Claim 2 further comprising: 

a plurality of tiransfbr modes, each allowing the transfer of different majiimum 
numbeis of bits of data in pai-allel over a given time period, vidth each mode selectable 
by negotiation between said host and client link drivers; and 
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whearein said tratisfer modes are djoiamically adjustable between said modes 
during transfer of data. 

7. Tiie interface of Claim 1 further comprising a plurality of packets usable to 
transfer video iriformation chosen from the group of Color Map, Bit Block Transfer, 
Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable type packets. 

8. The interface of Clmm 1 farther cornprising Filler type packets generated by said 
host to occupy periods of forward link transmission that do not have data. 

9. The interface of Claim 1 further comprising User-Defined Stream type packets 
for transferring interface-Qser defined data. 

10. The interface of Claim 1 further comprising a Link Shutdown type packet for 
transmission by said host to said client to terminate the transfer of data in either 
direction over said communication pathy 

11. The interface of Claini 1 ftirtlffif cornprising means for said client to wake up 

said host from a hibemation state. 

12. A Method of transferring digital data at a high rate between a host device and a 
client device over a cornmiinication path for presentation to a uiser, comprising: 

generating one or more of a plurality of pre-defined packet structures and linking 
them together to form a pre-defined communication protocol; 

communicating a pre-selected set of digital control and presentation data 
between said host and said client devices over Said cOttUnonieation path using said 
cotomutiication protocol; 

coupling at least one host linlc controller residing in said host device to said 
client device tiirough said communications path, the host linlc controller being 
configured to generate, tcansmit, and receive packets forming said commiinications 
protocol, and to foirm digital pijesentatjon data into one or more t3fpes of data packets- 
and 

transferring data in the form of packets over said communications path using 
said link contrallers. 
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13. The method of Claini 12 further comprising grouping said packets together 
within media frames far commumcatipn between, said host and client, the media frames 
having a pre-defiiied fixed length with a pre-detennined iiumbeT of said packets have 
differing and variable lengths. 

14. Hie method of Claim 12 furtiier comprising commencing transfer of packets 
from said host with a Sub-frame Header type pacisst. 

15. The method of Claim 12 further comprising transfening infofflcuttion between 
said host and client bi-directionally over said communications link. 

1:6. The method of Claim 12 further comprising at least one chent link controller 
residing in said client device coupled to said host device through said communication.? 
path, being configured to generate, transniit^ and receive packets forming said 
communications protocol, and to form digital presentation data into one or more types 
of data packets. 

17. The method of Claim 16 wherein said host link controller comprises one or more 
differential Ihie drivers; and said client link controller compdses one or more 
differential line receivers coupled to said communication path. 

18. The method of Claim 12 further compri.siing requesting display capabilitie.s 
information from the client by a host link controller so as to determine what type of data 
and data rates said client is capable of accommodating through said interface. 

19. The metiiod of Claim 12 further comprising operating a USB data interface by 
each of said link controlleis as a part of said communication path. 

20. The method of Claim 12 wherein said packets each comprise a packet length 
field, one or more packet data fields, and a cyclic redundancy check field. 
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2.1 .. The method of Claim 13 further comptising: 

negotiating between said host and client linic drivers the use of om of .a pteality 
of transfer modes in each direclicm, each allowing the transfer of different masiinuin 
rtumbers of bits of data in parallel over a given time period; and 

dynarnically adjustiiig between said transfer modes during transfer of data. 

22. The method of Claim t-Tlbc- cor-p' ^-r:; riro n ^ i o 2 d i -iTalitvof 
pack, 'h o lu-mui \iico infon-aatien c-osan tV tfic j^mup <.rCu w M 41 Ri! Block 
Transfer, Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable type- 
packets, 

23. The method of Claim 12 further comprising generating Filler type packets by 
said host to occupy periods of forward link transmission that do not have data.. 

24. The method of Claim 12 fuxiher cptnprismg teoninating the transfer pf data in 
either direction over said cooiniuiiication path using a Link- Shutdown type packet for 
transmission by said host to said client. 

25. The method of Claim 12 furfher comprising waking up said host from a 
hibernation state by commonication with said client. 

26. Apparatus fm- tmnsferting digiial data at a high rate between a host device and a 
client dcxdce over a communication path for presentation to a user, comprising: 

at least one host link controller disposed in said host device for generating one or 
more of a plurality of pre-defined packet structures and linking them together to form a 
pre-defined communication protocol, and for conmutiicating a pre-selected set. of 
digital control and presentation data between said host and said client devices over said 
communication path using said communication protocol; 

at least one cUent controller disposed in said client device and coupled to said 
host link cantroUer through said communications path; and 

each link controller being configured to geiiei-ate, transmit, and receive packets 
forming said communications protocol, and to form digital presentation data into one or 
more types of data packets. 
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27. The apparatus of Claim 26 wterein said host controller comprises a state 
machine. 

28. The apparatus of Claim 26 wherein said host controller coraprises a generdl 

purpose signal pfocessof; 

29. The apparatus of Claim 26 fiirther comprising a Sub-ft-aine Header type packet 
at the comrnehcing of transfer of packets from said host. 

30. The apparatus of Claim 26 wherein said linic contmllers are configured to 
transfer information between said host and client devices bi-directionally over said 
communications link. 

31. The apparatus of Claim 30 wherein said host controller comprises one or more 
differential line drivers; and said client receiver comprises om or more differential line - 
ireceivers coupled to said communication path. 

32. The apparatus of Claim 26 further comprising Video Stream type packets for 
video tj-pe data, and Apdio Stream type packets for audio type when transferring data 
from said host to said client for presentation to a client user. 

33. ihc appa.at„. -t -Jx.m ru.-.ici :r.ii..ir.s{iig one or more Reverse link 
Encapsulation type packets tor transieixing data from said client to said host. 

34. The apparatus of Claim 33 further- comprising at least one Display Capability 
type packet for communicating display or presentation capabilities from a client link 
controller to said host link controller. 

35. The apparatus of Claim 26 wherein said packets each comprise a packet length 
field, one or more packet data fields, and a cyche redundancy check field. 

36. Ttie ai^aratus of Claim 26 wherein said host and client link controllers are 
configured to use of one of a plurality of transfer modes in each difectioii, each allowing 
the transfer of different maximum numbers of bits of data in parallel over a given time 
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peridd; and being capable of being dynamically adjusting between said transfer mpd^ 
during transfer of ckta. 

37. The apparatus of Claim 26 furtlier comprising one or mere of a p-M:aiily of 
packiets for transfemrig video information chosen fitiTii the group of Color Map, Bit 
Block Transfer, Bitmap Area FiU, Bitniap Pattern Fill, and Trfljlsparent Color Enable 

[7pe packets. 

38. The apparatus of Claim 26 further comprising Filler type packets for transfer by 
said host to occupy periods of forvtfaid linktransrHission that do not have data. 

39. The apparatus of Claim 26 wherein said host controller is configured to transmit 
a Link Shutdown type packet to said client means for terminating the transfer of data in 
either direction over said commtinication path. 

40. l-'of u^t; in an i k .",..)r. t ^vs.i n (o ^ a ,\k miy digiUl dM.i id d lituli nu 
between a host device and a chent device over a communication path ixtr presentation to 
a user, a computer program product comprising: 

a computer usable medium ha\'ing computer readable program code means 
embodied in said medium for causing an application program to execute on the 
eomputier system, sai<i ebniptitjer readable program code means comprising: 

a computer readable first program code means for causing the compuler system 
to generate one or more of a plurality of pre-defined packet structures and link them 
together to form a pre-defined communication protocol; 

a computer readable second program code means for causing the computer 
system to commimicate a pre-selected set of digital control and. presentation data 
between said host and said client devices over said communiGation path using said 
communication ih-o£oco1; 

a computer readable third program code means for causing the computer system 
to couple at least one host link controller disposed in said host device to at l^t one 
client controller deposed in said client deviqe through said communications path, the 
linlc controllers being configured to generate, transniit, and receive packets forming said 
commuiiications protocol, and to form digital presentation data into one or more typ^ 
of data packets; and 
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a computer jreadable fourth program code means for causing the computer 
system to transfer data in the form of packets over said comnmnications path using said 
link controllej^. 

41. Apparatus fortransfcirii i (' ' i i b ^ st. urv, r ,i d a 
client device over a commu i c i t ijuipii--u «=, 

means for gcncratir^ , p Cvtirtd pt.^.vet bt uttares 

and linking tf eiii U)^el! ef t Km ^["■-^eircl pmj"nri o" pio'-occ 

mc-ins. i<> 1 1 iri'i ipiCfiting a pre selected bcl ot digiral contioi ttna piesei"aTion 
data boivvs \ s ml s <;s «iid said client devices over s<4id commumcation path using said 
communication protocol: 

racm' tc- ^oapl at least two link cor.irolv- tri''i,lhr thr i -^h -.aid 
comniniiKaf ot>'- pi*n o"l ei^h of said host and cbeni ird each OLir ^ ^ iiiigated to 
gene: n uir«int nuS •-i.c-f^ e pi iceK oi'iiwi:. >■ -aJ o^unin -iti^n'- p-jloool, and to 
form digital presentation data into one or more types of data:packets; and 

means for transferring data in the form of packets over said communications 
path using said Hnk controllers. 

42. The appEtratus of Claim 41 further comprising means for commencing transfer of 
packets fi-om said host with a Sub-frame Header type packet. 

43. The apparatus of Claim 41 further comprising means for transferring 
information between said host and client bi-diiectionally over said commimications 
Hnk. 

44. The apparatus of Claim 41 further comprising means for requesting display 
capabilities information from the client by a host link controller so as to determine what 
type of data and data rates said client is capable of accommodating through said 

interface. 

45. The apparatus of Claim 44 further compiising means for communicating display 
or presmtation capabilities fircm a client link controller to said host link controller using 
at least one Display Capability type packet. 
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46 . The apparatus of Qaim 42 further comprising: 

meani? for negotjating .between s.aid.hDst and client link drivers the use of one of 
a plurality of transfer modes in each directioo, each allowing the transfer of different 
maximuiii numbers of bits of data in parallel over a given time period; sM 

rtieafts fof dynamically adjusting between said ti-aiisfer modes during transfer of 

data. 

47. The d.f\iA Jt- t ( Im 4 ir n.r comprising means for using or;e or more of a 
plurality of pdtki_ c to !d\ sfei Mdeo information chosen froni the group of Color Map, 
Bit Bl.-ck J au^k. Bitraap Area Fill, Bitmap Pattern Fill, aiid Tratispafent Color 

Enable type packets, 

'iS 4 p'-o cbb jr io'- U'~c n an electronic svstem f'^r trar ternn^ ag.tc.. data jl a hn',-^ 
rtti- Vi VLf'n 1 f osi de\Ke 4 0 ( lien o M^co^cr^ ^^mmurKd+^o" path, the p'ocess^r 
vfufi i»i > I ^ i It nri >n\i • • il f x i< -d fi nl j i t- ^ ii > ii^- n- 
l.ik , , I. h I (I I isi , r I ,1 I n io IV . o U n i U 

prc^e^tativii (1 i a ni i s r. pi ^ ^ .Ua j. ivkt i.'- ^.o ih iL.ii.t,dtu. a ./le ^ielecied set 
of c"g"£" L II tiD t „ (1 . - „ata between »aid hcst ahd scid Ci^ent devioes o/er 
said coramuricauoi;! patli using said communication protocol, and transter data m tne 
form of packets over said communications path. 

49. A state machine for use in obtaining synchronization iii an electronic system 
transferring digital data at a high rate between a host device and a client device over a 
communication, path, tlie state machine configured to have at least one Async Frames 
State synchronizatioti state, at least two Acquiring Sync States synchronization states, 
and at least three In-Sync States synehtonization states. 

50, A state machine for use in obtaining synchronization in an: electronic system 
transfenttig digital data at a high rate between a host de'vice and a client (kyice over a 
communication path, the state machine configured to have at least one Acquiring Sync 
States synchronixation states, and at least two In-Sync States synchronization states. 
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51. The state machine of Claim SO, wherein one condition focr shifting between an 
Acquiring Sync State and a first In-Sync State is detecting the presence of a 
synchronization pattern in the communication link. 

52. Tile state machine of Claim 5 1 , wherein a second condition for shifting between 
an Acquiring Sync State and a fust Jh-S>t.c . ie the presence of a sub- 
frame header packet and good CRC value at ti n ^rru bzi :i.;a. v. 

53. The state machine of Claim 50, wherein one oonuii- ji. jyi shifting betwieen a 
first In-Sync State and an Acquiring Synr Stdt^: \ i;le!.e..tj<iig the presence of no 
synchronization pattern or a bad CRC value at a sub-fi ame boundary; 

54. The state machine of Claiitt 50, wherein one condition foi- shifting between a 
first In-Sync State and a second In-Sync State is delecting the presence of no 
synchronization pattern or a bad CRC value at a suli-frame boundary. 

55. The state machine of Claim 50. wherein one condition for shifting between an 
Acquiring Sync State and a first In--S:.mc State is detecting the presence of a 
synchronization pattern in the communication link is detecting the prsssence of a good 
packet CRC value. 



56. The state machine of Qaim 50, wherein a condition for shifting between a first 
In-Sync State and an Acquiring Sync State is detecting the presence of a bad CRC value 
in a packet. 

57. A state machine for use in obtaining synclironization iii an electronic system 
transferring digital data at a high rate between a host device and a client device over a 
communication pafb, liic state machine configured to have at least one Acqtiiring Sync 
States synchronization states, and at least two In-Sync S.tates synchroiii2ation states, 
wherein a condition for shifting directly between a firat In-Syiic Staite and an Acquiring 
Sync State is detecting the presence of a bad CRC value in any of a seties of packets. 
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58. The state machine of Claim 57, wherein a condition for shiifting directly between 
a first In-Syne State and an Acquiring Sync State is detecting when the unique woitl 
does not occur at a time it is expected to arrive. 

59. The method of Claim 26 farther comprising waking up a commimicaliQn link by 
driving a data line to a Mgll state for at least 10 clock cycles and starting to transmit a 

strobe signal as if the data line was zero, by said host. 

60. I'tie method of Claim 51* further comprising driving the data line low for 50 
clock cycles by said host while continuing to transniit a strobe signal after the host has 

driven the data line high for 150 clock cyclea. 

61. The method of Claim 59 further comprising beginning to transmit the .first sub- 
frame header packet by said host. 

62. The method of Claim 60 further comprising counting at least 150 continuous 
clock cycles of the data line being high, followed by at least 50 continuous clock cycles 
of the data luje being low, by said client. 

63. The method of Claim 62 further comprising searching for the unique word of the 
first sub-firame by said client. 

64. The method of Claim 60 further comprising stopping driving the data line high 
by said client after the clientcounts 70 continuous clock cycles of the data being high 

65. The method of Claim 64 further comprising counting another SO continoous 
clock cycles of the data line being high to reach the 150 clock cycles of the data line 
being high by said cli ent, and looking for 50 clock cycles of the data line being low, and 

looldng for the unique word. 

66. The method of Claim 26 further comprising counting the number of clock cycles 
occurring until a one is sampled by said host, by sampling the data line on both the 
rising and falling edges dnjing die reverse timing paeket. 
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67. A method of transferring error codes in a coicmunication system in which digital 
data is transferred in the form of packets haying CRC values between a host device mid 
a client device over a communication path comprising detecting tiie presence of an 
error, selecting a pre-detenuined er ror code corresjpbnding to said enor, and ovec- 
writing tlie CRC value with said code. 

68. The method of Claim 67 further comprising overwriting said CRC value hi 
successive ones of packets being transfen^d until said error is corrected. 

69,. A method of transferring digital data at a high rate between a host device atid a 
client device over a communication path for presentation to a user, comprising: 

generating one or more of a plurahty of pre-defined packet structures each 
inclxiding at least one CRC field, and. linking them together to form a pre-defined 
communication protocol; 

communicating a pre-sejected set of distal control and presentation data 
between said host and said client devices over said ca^lInunication path using said 
corBm,unieation protocol; 

coupling at least one host link controller residing in said host device to said 
client device through said communications path, the host link controller being 
configured to generate, transmit, and receive packets forming said communications 
protocol, and to form digital presentation data into one or more types of data packets; 

transferring data in the form of packets over said communications path using 
said link controllers; 

detecting the presence of an error for tiie communication link; 

selecting a pre-detemiined error code corresponding to said error; and over- 
writing the CRC valuie with said code. 

70. The method of Claim 69 further comprising overwriting said CRC value in 
successive ones of packets being transferred until said error is corrected. 



wo 2004/110021 



1/53 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 



2/53 




wo 2004/110021 



PCT/US2004/017579 



3/53 



1^ f 



_J L__ 



LL 





111 cc 
_l lU 


CO ^ 


1 


. 05 

ff! 2 


w 


< 5 
y- CL 




s[. 




o 

X 


eg 


WIRE 
TELEI 


a. I 
1 
1 


WIRE 

MO! 



wo 2004/110021 



PCT/US2004/017579 



4/53 




wo 2004/110021 PCT/US2004/017579 
5/53 




wo 2004/110021 



PCT/US2004/017579 



6/53 




wo 2004/110021 



PCT/US2004/017579 



7/53 




wo 2004/110021 



PCT/US2004/017579 



8/53 




wo 2004/110021 



PCT/US2004/017579 



9/53 




CM 



wo 2004/110021 



PCT/US2004/017579 



10/53 



CL cn 



a o 



< £ 



J 



LL. 



0) CO CC 

^ Q O 



2 o 



E B 

i i 



E -Q 



C5 

LL 



wo 2004/110021 PCT/US2004/017579 



CD ■- 



tj3 — — 



"1 

"m o 



wo 2004/110021 



PCT/US2004/017579 



12/53 




wo 2004/110021 



PCTyUS2004/017579 




wo 2004/110021 



14/53 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 



I 

CM 

t g 



il 



ii 



If 



SI 

i 



If 



II 



[J 



CO 
CM 

i 



wo 2004/110021 



PCT/US2004/017579 



i 

if) 

i 



1^ 



I 





o 


1 

J3 
CVl 


Q 




1 


1 


1 


CM 






i 


i 


If 










1 


i 




1 




1 




It 


1 

CM 


It 



00 
tM 

s 



wo 2004/110021 



18/53 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 



19/53 




wo 2004/110021 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 



21/53 




2004/110021 



PCT/US2004/017579 



22/53 



J u 



r 



E i 
1 1 



ii 



< 

CO 

(3 



r 



3 



wo 2004/110021 



PCT/US2004/017579 



23/53 



5 c (ft 



g .9 



d 

LL 



0 
0- 



0 



0 



t;5 



wo 2004/110021 



PCT/US2004/017579 



24/53 



o 



O 

d 

LL 



CJ 




wo 2004/110021 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 




FIG. 42 



wo 2004/110021 



PCT/US2004/017579 



•- O < 



0) Q. 



CO 



J± 1_ 



J- i 



B E » 
0 O o 



5 i 

Q O 
SC. 



wo 2004/110021 



28/53 



PCT/US2004/017579 




wo 2004/110021 



PCT/US2004/017579 



29/53 






wo 2004/110021 



PCT/US2004/017579 



30/53 




wo 2004/110021 



31/5.3 



PCT/US2004/017579 



4900 




cond 1 = Sub-frame header packet & good CRC at frame boundary, 

Frame Length > 0 
cond 2 - no sync pattern or bad CRC at frame boundary 
cond 3 = found syno pattern, Frame Length = 0 
cond 4 = received link shutdown packet 
cond 5 = found sync pattern, Frame Length > 0 
cond 6 = frame header packet & good CRC, Franne Length > 0 



FIG. 49 
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cond 62 = no sync pattern or bad CRC at sub-frame boundary 

cond 63 = received link shutdown packet 
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cond 65 = Unique word incorrect 
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